По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В предыдущих лекциях обсуждалось правило кратчайшего пути и два алгоритма (или, возможно, системы) для поиска путей без петель через сеть. Существует широкий спектр таких систем—их слишком много, чтобы охватить их в отведенное время для изучения, - но для сетевых администраторв важно быть знакомыми хотя бы с некоторыми из этих систем. В этих лекциях сначала рассматривается алгоритм поиска кратчайшего пути Дейкстры, вектор пути и два различных алгоритма непересекающихся путей: Suurballe и Maximally Redundant Trees (MRTs). Наконец, в этих лекциях будет рассмотрена еще одна проблема, которую должны решить управляющие плоскости: обеспечение двусторонней связи через сеть.
Алгоритм Дейкстры Shortest Path First.
Алгоритм Дейкстры Shortest Path First (SPF), возможно, является наиболее широко известной и понятной системой для обнаружения Loop-Free путей в сети. Он используется двумя широко распространенными протоколами маршрутизации и во многих других повседневных системах, таких как программное обеспечение, предназначенное для поиска кратчайшего пути через дорожную сеть или для обнаружения соединений и паттернов соединений в социальных сетях.
Алгоритм Дейкстры в псевдокоде использует две структуры данных. Первый - это предварительный список или TENT; этот список содержит набор узлов, рассматриваемых для включения в дерево кратчайшего пути (Shortest Path Tree). Второй - PATH; этот список содержит набор узлов (а следовательно, и каналы), которые находятся в дереве кратчайшего пути.
01 move "me" to the TENT
02 while TENT is not empty {
03 sort TENT
04 selected == first node on TENT
05 if selected is in PATH {
06 *do nothing*
07 }
08 else {
09 add selected to PATH
10 for each node connected to selected in TOPO
11 v = find node in TENT
12 if (!v)
13 move node to TENT
14 else if node.cost < v.cost
15 replace v with node on TENT
16 else
17 remove node from TOPO
18 }
19 }
Как всегда, алгоритм менее сложен, чем кажется на первый взгляд; ключом является сортировка двух списков и порядок, в котором узлы обрабатываются вне списка TENT. Вот несколько примечаний к псевдокоду перед рассмотрением примера:
Процесс начинается с копии базы данных топологии, называемой здесь TOPO; это будет яснее в примере, но это просто структура, содержащая исходные узлы, целевые узлы и стоимость связи между ними.
TENT - это список узлов, которые можно условно считать кратчайшим путем к любому конкретному узлу.
PATH - это дерево кратчайшего пути (SPT), структура, содержащая loop-free путь к каждому узлу и следующий переход от «меня» к этому узлу.
Первым важным моментом в этом алгоритме является сохранение только узлов, уже каким-то образом связанных с узлом в списке PATH в TENT; это означает, что кратчайший путь в TENT - это следующий кратчайший путь в сети.
Второй важный момент в этом алгоритме - это сравнение между любыми существующими узлами TENT, которые подключаются к одному и тому же узлу; это, в сочетании с сортировкой TENT и отделением TENT от PATH, выполняет правило кратчайшего пути.
Имея в виду эти моменты, рисунки с 1 по 9 используются для иллюстрации работы алгоритма SPF Дейкстры.
На каждой из следующих иллюстраций вместе с сопроводительным описанием показан один шаг алгоритма SPF в этой сети, начиная с рисунка 2.
В точке, показанной на рисунке 2, A был перемещен из TOPO в TENT, а затем в PATH. Стоимость исходного узла всегда равна 0; эта линия включена для начала расчета SPF. Это представляет строки с 01 по 09 в псевдокоде, показанном ранее. На рисунке 3 показан второй этап расчета SPF.
На рисунке 3 каждый узел, подключенный к A, был перемещен из TOPO в TENT; это строки с 10 по 17 в псевдокоде, показанном ранее. Когда этот шаг начался, в TENT была только A, поэтому в TENT нет существующих узлов, которые могли бы вызвать какие-либо сравнения метрик. Теперь TENT отсортирован, и выполнение продолжается со строки 03 в псевдокоде. Рисунок 4 демонстрирует это.
На рисунке 4 один из двух путей с кратчайшей стоимостью - к B и F, каждый со стоимостью 1 - был выбран и перемещен в PATH (строки 05–09 в псевдокоде, показанном ранее). Когда B перемещается из TENT в PATH, любые узлы с началом B в TOPO перемещаются в TENT (строки 10-17 в псевдокоде). Обратите внимание, что C еще не был в TENT, прежде чем он был задействован посредством перехода B к PATH, поэтому сравнение показателей не выполняется. Стоимость для C - это сумма стоимости его предшественника в PATH (который равен B со стоимостью 1) и связи между двумя узлами; следовательно, C добавляется к TENT со стоимостью 2. TENT сортируется (строка 3 псевдокода), поэтому процесс готов к повторному запуску. На рисунке 5 показан следующий шаг в этом процессе.
На рисунке 5 был выбран кратчайший путь к TENT, и F переместился от TENT к PATH. Между F и E существует связь (показанная на предыдущих иллюстрациях как [E, F]), но путь через F к E имеет ту же стоимость, что и путь [A, E], поэтому эта линия не добавляется в TENT. Скорее он остается неактивным, поскольку не рассматривается для включения в SPT, и удаляется из TOPO. На рисунке 6 показан следующий шаг в процессе, который переместит один из путей метрики 2 в PATH.
Примечание. Большинство реальных реализаций поддерживают перенос нескольких путей с одинаковой стоимостью из TENT в PATH, поэтому они могут пересылать трафик по всем каналам с одинаковой метрикой. Это называется многолучевым распространением с равной стоимостью или ECMP. Для этого есть несколько различных способов, но они в этих лекциях не рассматриваются.
На рисунке 6 путь к C через B со стоимостью 2 был перемещен в PATH, а путь к D через [A, B, C, D] перемещен в TENT. Однако при перемещении этого пути к TENT строка 11 в псевдокоде находит существующий путь к D в TENT, путь [A, D], со стоимостью 5. Метрика нового пути, 3, ниже чем метрика существующего пути, 5, поэтому путь [A, D] удаляется из TENT, когда добавляется путь [A, B, C, D] (строка 15 в псевдокоде). На рисунке 7 показан следующий шаг, на котором линия оставшейся стоимости 2 перемещается из TENT в PATH.
На рисунке 7 путь к E стоимостью 2 был перемещен из TENT в PATH. G был перемещен в TENT стоимостью 4 (сумма [A, E] и [E, G]). Другой сосед E, F, исследуется, но он уже находится в PATH, поэтому не рассматривается для включения в TENT. На рисунке 8 показан следующий шаг, который перемещает D в PATH.
На рисунке 8 D общей стоимостью 3 перемещен из TENT в PATH. Это учитывает соседа D, G, последнюю запись в TOPO, для TENT. Однако уже существует путь к G с общей стоимостью 4 через [A, E, G], поэтому строка 14 в псевдокоде завершается ошибкой, и путь [D, G] удаляется из TOPO. Это последний SPT.
Основная трудность в понимании алгоритма Дейкстры заключается в том, что правило кратчайшего пути не выполняется в одном месте (или на одном маршрутизаторе), как это происходит с Bellman-Ford или Diffusing Update Algorithm (DUAL). Кратчайший путь (по-видимому) проверяется только при перемещении узлов из TOPO в TENT - но на самом деле сортировка самого TENT выполняет другую часть правила кратчайшего пути, и проверка по PATH для существующих узлов составляет еще один шаг в процесс, делающий процесс трехступенчатым:
Если путь к узлу длиннее, чем любой из TENT, то путь к TENT является более коротким путем по всей сети.
Путь, который поднялся к вершине TENT через сортировку, является самым коротким к этому узлу в сети.
Если путь перемещается к PATH от вершины TENT, это кратчайший путь к этому узлу в сети, и любые другие записи в TOPO к этому узлу следует отбросить.
При наличии базового алгоритма полезно рассмотреть некоторые оптимизации и расчет Loop-Free Alternates (LFAs) и remote Loop-Free Alternates (rLFAs).
Частичный и инкрементный SPF
Нет особой причины, по которой весь SPT должен перестраиваться каждый раз, когда происходит изменение топологии сети или информации о доступности. Рассмотрим рисунок 9 для объяснения.
Предположим, G теряет связь с 2001: db8: 3e8: 100 :: / 64. Устройству A не требуется пересчитывать свой путь к любому из узлов сети. Доступный пункт назначения - это просто лист дерева, даже если это набор хостов, подключенных к одному проводу (например, Ethernet). Нет причин пересчитывать весь SPT, когда один лист (или любой набор листьев) отключается от сети. В этом случае только лист (IP-адрес Интернет-протокола или доступный пункт назначения) должен быть удален из сети (или, скорее, пункт назначения может быть удален из базы данных без каких-либо изменений в сети). Это частичный пересчет SPT.
Предположим, что канал [C, E] не работает. Что делает А в этом случае? Опять же, топология C, B и D не изменилась, поэтому у A нет причин пересчитывать все дерево. В этом случае A может удалить все дерево за пределами E. Чтобы вычислить только измененную часть графа, выполните следующие действия:
Удалите отказавший узел и все узлы, которые нужно достичь через точку E.
Пересчитайте дерево только от предшественника C (в данном случае A), чтобы определить, есть ли альтернативные пути для достижения узлов, ранее доступных через E до того, как канал [C, E] не доступен.
Это называется инкрементным SPF.
Расчет LFA и rLFA.
Bellman-Ford не вычисляет ни соседей ниже по потоку, ни LFA, и, похоже, не располагает необходимой для этого информацией. DUAL по умолчанию вычисляет нисходящих соседей и использует их во время конвергенции. А как насчет протоколов на основе Дейкстры (и, соответственно, аналогичных алгоритмов SPF)? На рисунке 10 показан простой механизм, который эти протоколы могут использовать для поиска LFA и соседних узлов ниже по потоку.
Определение нисходящего соседа - это такое, при котором стоимость достижения соседом пункта назначения меньше, чем локальная стоимость достижения пункта назначения. С точки зрения А:
A знает местную стоимость проезда к месту назначения на основе SPT, созданного с помощью SPF Дейкстры.
A знает стоимость B и C, чтобы добраться до места назначения, вычитая стоимость каналов [A, B] и [A, C] из рассчитанной на местном уровне стоимости.
Следовательно, A может сравнивать локальную стоимость со стоимостью от каждого соседа, чтобы определить, находится ли какой-либо сосед в нисходящем направлении по отношению к любому конкретному месту назначения. Определение LFA:
Если затраты соседа для «меня» плюс затраты соседа на достижение пункта назначения ниже, чем местные затраты, соседом является LFA.
Вернее, учитывая:
NC - это стоимость соседа до пункта назначения.
BC - это стоимость соседа для меня.
LC - местная стоимость до места назначения.
Если NC + BC меньше LC, то соседом является LFA. В этом случае A знает стоимость каналов [B, A] и [C, A] с точки зрения соседа (она будет содержаться в таблице топологии, хотя не используется при вычислении SPT с использованием алгоритма Дейкстры). Таким образом, LFA и нисходящие соседи требуют очень небольшой дополнительной работы для расчета, но как насчет удаленных LFA? Модель P/Q Space обеспечивает простейший способ для алгоритмов на основе Дейкстры вычисления соседних узлов и LFA. Рисунок 11 используется для иллюстрации изнутри P/Q Space.
Определение пространства P - это набор узлов, доступных с одного конца защищенного соединения, а определение пространства Q - это набор узлов, достижимых без пересечения защищенного канала. Это должно предложить довольно простой способ вычисления этих двух пространств с помощью Дейкстры:
Рассчитайте SPT с точки зрения устройства, подключенного к одному концу линии связи; удалить линию связи без пересчета SPT. Остальные узлы доступны с этого конца линии.
На рисунке 11 E может:
Вычислите пространство Q, удалив линию [E, D] из копии локального SPT и всех узлов, для достижения которых E использует D.
Вычислите пространство P, вычислив SPT с точки зрения D (используя D в качестве корня дерева), удалив линию [D, E], а затем все узлы, для достижения которых D использует E.
Найдите ближайший узел, достижимый как из E, так и из D, с удаленной линией [E, D].
SPF Дейкстры - это универсальный, широко используемый алгоритм для вычисления Shortest Path Trees через сеть.
Классический стандарт связующего дерева работает нормально, но в настоящее время для современных сетей он слишком медленный 🐌
В настоящее время мы наблюдаем в наших сетях все больше и больше маршрутизации. Протоколы маршрутизации, такие как OSPF и EIGRP, намного быстрее адаптируются к изменениям в сети, чем spanning-tree. Чтобы не отставать от скорости этих протоколов маршрутизации, была создана еще одна разновидность связующего дерева... (rapid spanning tree) быстрое связующее дерево.
Rapid spanning tree - это не революция spanning tree, а его эволюция. Некоторые вещи были изменены для того, что бы ускорить процесс, но с точки зрения конфигурации - это то же самое, что классический spanning tree . Я называю оригинальное spanning tree "классическим spanning tree".
Азы Rapid spanning tree
Помните состояние портов spanning tree? У нас есть блокирующее, прослушивающее, обучающее и пересылающее состояние порта. Это первое различие между spanning tree и rapid spanning tree. Rapid spanning tree имеет только три состояния портов:
Отбрасывание;
Обучение;
Пересылка.
Вы уже знакомы с состоянием порта в режиме обучения и пересылки, но отбрасывание - это новое состояние порта. В основном он объединяет в себе блокировку и прослушивание состояния порта.
Вот хороший обзор с различными состояниями портов для spanning tree и rapid spanning tree. В таблице отображено состояние портов: активны ли они и узнают ли они MAC-адреса или нет.
Помните ли вы все остальные роли портов, которые есть у spanning tree? Давайте сделаем небольшой обзор, и будет показано отличие от rapid spanning tree.
Коммутатор с лучшим ID моста (priority + MAC -адрес) становится корневым мостом. Другие коммутаторы (non-root) должны найти кратчайший путь стоимости к корневому мосту. Это корневой порт. Здесь нет ничего нового, все это работает аналогично и в rapid spanning tree.
На каждом сегменте может быть только один назначенный порт, иначе мы получим петлю. Порт станет назначенным портом, если он сможет отправить лучший BPDU. Коммутатор А, как корневой мост, всегда будет иметь лучшие порты, поэтому все интерфейсы будут назначены. Интерфейс fa0/16 на коммутаторе B будет назначенным портом в моем примере, потому что он имеет лучший идентификатор моста, чем коммутатор C. Здесь все еще нет ничего нового по сравнению с классическим связующим деревом.
Коммутатор C получает лучшие BPDU на своем интерфейсе fa0/16 от коммутатора B, и таким образом он будет заблокирован. Это альтернативный порт, и это все еще то же самое, что и для rapid spanning tree.
Вот вам новый порт, взгляните на интерфейс fa0/17 коммутатора B. Он называется резервным портом и является новым для rapid spanning tree. Однако вы вряд ли увидите этот порт в производственной сети. Между коммутатором B и коммутатором C был добавлен хаб. Обычно (без промежуточного концентратора) оба fa0/16 и fa0/17 будут назначены портами. Из-за хаба интерфейсы fa0/16 и fa0/17 коммутатора B теперь находятся в одном домене коллизий. Fa0/16 будет выбран в качестве назначенного порта, а fa0/17 станет резервным портом для интерфейса fa0/16. Причина, по которой коммутатор B видит интерфейс fa0/17 в качестве резервного порта, заключается в том, что он получает свои собственные BPDU на интерфейсах fa0/16 и fa0/17 и понимает, что у него есть два соединения с одним и тем же сегментом. Если вы удалите хаб, то fa0/16 и fa0/17 будут назначены портами точно так же, как classic spanning tree.
BPDU отличается для rapid spanning tree. В classic spanning tree поле flags использовало только два бита:
Topology change.;
Topology change acknowledgment.;
Теперь используются все биты поля flags. Роль порта, который создает BPDU, будет добавлена с помощью поля port role, оно имеет следующие параметры:
Unknown;
Alternate / Backup port;
Root port;
Designated port.
Эта BPDU называется BPDUv2. Коммутаторы, работающие со старой версией spanning tree, проигнорируют эту новую версию BPDU. Если вам интересно ... rapid spanning tree и старое spanning tree совместимы! Rapid spanning tree способно работать с коммутаторами, работающими под управлением более старой версии spanning tree.
Что поменялось
BPDU теперь отправляются каждый hello time. Только корневой мост генерирует BPDU в classic spanning tree, и они ретранслировались non-root, если они получали его на свой корневой порт. Rapid spanning tree работает по-разному...все коммутаторы генерируют BPDU каждые две секунды (hello time). Это hello timeпо умолчанию, но вы можете его изменить.
classic spanning tree использует максимального время жизни (20 секунд) для BPDU, прежде чем они будут отброшены. Rapid spanning работает по-другому! BPDU теперь используются в качестве механизма поддержания активности, аналогичного тому, что используют протоколы маршрутизации, такие как OSPF или EIGRP. Если коммутатор пропускает три BPDU от соседнего коммутатора, он будет считать, что подключение к этому коммутатору было потеряно, и он немедленно удалит все MAC-адреса.
Rapid spanning tree будет принимать низшие BPDU. Classic spanning tree игнорирует их. Скорость перехода (время сходимости) является наиболее важной характеристикой rapid spanning tree. Classic spanning tree должно было пройти через состояние прослушивания и обучения, прежде чем оно переведет интерфейс в forwarding состояние, это занимает 30 секунд (таймер по умолчанию). Classic spanning было основано на таймерах.
Rapid spanning не использует таймеры, чтобы решить, может ли интерфейс перейти в forwarding состояние или нет. Для этого он будет использовать переговорный (negotiation) механизм. Чуть позже я покажу вам, как это работает.
Помните ли вы понятие portfast? Если мы включим portfast во время запуска classic spanning tree, оно пропустит состояние прослушивания и обучения и сразу же переведет интерфейс в forwarding состояние. Помимо перевода интерфейса в forwarding состояние, он также не будет генерировать изменения топологии, когда интерфейс переходит в состояние UP или DOWN. Мы все еще используем portfast для rapid spanning tree, но теперь он называется пограничным портом (edge port).
Rapid spanning tree может только очень быстро переводить интерфейсы в forwarding состояние на edge ports (portfast) или интерфейсы типа point-to-point. Он будет смотреть на link type, и есть только два ink types:
Point-to-point (full duplex);
Shared (half duplex).
Обычно мы используем коммутаторы, и все наши интерфейсы настроены как full duplex, rapid spanning tree видит эти интерфейсы как point-to-point. Если мы введем концентратор в нашу сеть, то у нас будет half duplex, который рассматривается как shared interface к rapid spanning-tree.
Позвольте мне описать механизм быстрой синхронизации spanning tree, используя рисунок выше. Коммутатор А сверху - это корневой мост. Коммутатор B, C и D- некорневые мосты (non-root).
Как только появится связь между коммутатором А и коммутатором B, их интерфейсы будут находиться в режиме блокировки. Коммутатор B получит BPDU от коммутатора A, и теперь будет происходить согласование, называемое синхронизацией.
После того, как коммутатор B получил BPDU от корневого моста, он немедленно блокирует все свои порты, не обозначенные в списке non-edge. Non-edge порты - это интерфейсы для подключения к другим коммутаторам, пока edge порты- интерфейсы, настроены как portfast. Как только коммутатор B блокирует свои non-edge порты, связь между коммутатором A и коммутатором B переходит в forwarding состояние.
Коммутатор B также выполнит операцию синхронизации как с коммутатором C, так и с коммутатором D, чтобы они могли быстро перейти в forwarding состояние.
Главное, что следует усвоить здесь, заключается в том, что rapid spanning tree использует этот механизм синхронизации вместо механизма "таймера", который использует classic spanning tree (прослушивание → обучение → forwarding).
Давайте увеличим масштаб механизма синхронизации rapid spanning tree, подробно рассмотрев коммутатор A и коммутатор B. Сначала интерфейсы будут заблокированы до тех пор, пока они не получат BPDU друг от друга. В этот момент коммутатор B поймет, что коммутатор A является корневым мостом, потому что он имеет лучшую информацию BPDU. Механизм синхронизации начнется, потому что коммутатор А установит proposal bit в поле flag BPDU.
Коммутатор B получает предложение от коммутатора A и понимает, что он должен что-то сделать. Он заблокирует все свои non-edge интерфейсы и запустит синхронизацию в направлении коммутатора C и коммутатора D.
Как только коммутатор B перевед свои интерфейсы в режим синхронизации, это позволит коммутатору А узнать об этом, отправив соответствующее соглашение.
Это соглашение является копией proposal BPDU, где proposal bit, был switched off, а agreement bit - switched on. Интерфейс fa0/14 на коммутаторе B теперь перейдет в режим forwarding.
Как только коммутатор A получит соглашение от коммутатора B, он немедленно переведет свой интерфейс fa0/14 в режим пересылки. А как насчет интерфейса fa0 / 16 и fa0 / 19 на коммутаторе B?
Точно такой же механизм синхронизации будет иметь место и сейчас на этих интерфейсах. Коммутатор B направит предложение по своим интерфейсам fa0/16 и fa0/19 в сторону коммутатора C и коммутатора D.
Коммутатор C и коммутатор D не имеют никаких других интерфейсов, поэтому они отправят соглашение обратно на коммутатор B.
Коммутатор B переведет свои интерфейсы fa0/16 и fa0/19 в режим forwarding, и на этом мы закончим. Этот механизм синхронизации - всего лишь пара сообщений, летающих туда-сюда, и очень быстро, это намного быстрее, чем механизм на основе таймера classic spanning tree!
Что еще нового в rapid spanning tree?
Есть еще три вещи:
UplinkFast;
Механизм изменения топологии;
Совместимость с классическим связующим деревом.
Когда вы настраиваете classic spanning tree, вы должны включить UplinkFast самостоятельно. Rapid spanning tree использует UpLinkFast по умолчанию, вам не нужно настраивать его самостоятельно. Когда коммутатор теряет свой корневой порт, он немедленно переводит свой альтернативный порт в forwarding.
Разница заключается в том, что classic spanning tree нуждалось в multicast кадрах для обновления таблиц MAC-адресов всех коммутаторов.
Нам это больше не нужно, потому что механизм изменения топологии для rapid spanning tree отличается. Так что же изменилось в механизме изменения топологии?
С classic spanning tree сбой связи вызвал бы изменение топологии. При использовании rapid spanning tree сбой связи не влияет на изменение топологии. Только non-edge интерфейсы (ведущие к другим коммутаторам), которые переходят в forwarding состояние, рассматриваются как изменение топологии. Как только коммутатор обнаружит изменение топологии это произойдет:
Он начнет изменение топологии при значении таймера, которое в два раза превышает hello time. Это будет сделано для всех назначенных non-edge и корневых портов.;
Он будет очищать MAC-адреса, которые изучаются на этих портах.;
До тех пор, пока происходит изменение топологии, во время активности таймера, он будет устанавливать бит изменения топологии в BPDU, которые отправляются из этих портов. BPDU также будет отправлен из своего корневого порта.;
Когда соседний коммутатор получит этот BPDU с установленным битом изменения топологии, произойдет следующее:
Он очистит все свои MAC-адреса на всех интерфейсах, кроме того, на котором он получил BPDU с включенным изменением топологии.;
Он запустит изменение топологии во время самого таймера и отправит BPDU на все назначенные порты и корневой порт, установив бит изменения топологии.;
Вместо того, чтобы отправлять изменения топологии вплоть до корневого моста, как это делает classic spanning tree, изменение топологии теперь быстро распространяется по всей сети.
И последнее, но не менее важное, давайте поговорим о совместимости. Rapid spanning tree и classic spanning tree совместимы. Однако, когда коммутатор, на котором работает Rapid spanning tree, связывается с коммутатором, на котором работает classic spanning tree, все функции скоростной передачи данных не будут работать!
В приведенном выше примере у меня есть три коммутатора. Между коммутатором A и коммутатором B мы запустим rapid spanning tree. Между коммутатором B и коммутатором C мы вернемся к classic spanning tree.
DNS спуфинг (spoofing), так же известный как отравление DNS кэша (cache poisoning), вид атаки, когда DNS кэш заполняется поддельными данными, в результате чего пользователь перенаправляется на вредоносный сайт.
Отравление DNS-кэша является результатом уязвимостей, которые позволяют преступникам отправлять поддельные DNS-ответы, которые серверы доменных имен (DNS - Domain Name Server) сохраняют в своих кэшах.
Обычно скомпрометированная запись перенаправляет пользователя на поддельный веб-сайт, который злоумышленники используют для совершения преступных действий, таких как распространение вредоносных программ или кража реквизитов кредитных карт, паролей, финансовых данных или другой конфиденциальной и частной информации.
При отравлении DNS-кэша сервер кэша DNS сохраняет нелегитимный адрес, предоставленный злоумышленником, а затем выдает его пользователям, запрашивающим подлинный веб-сайт. В большинстве случаев он может выглядеть аналогично аутентичному веб-сайту, поэтому посетителям становится сложнее отличить поддельный сайт от настоящего.
Влияние отравления DNS-кэша
DNS спуфинг, обычно трудно обнаружить и может оказать большое негативное влияние, особенно для популярных веб-сайтов или веб-приложений со большим количеством посещений или зарегистрированными пользователями. Это представляет большой риск, особенно в некоторых чувствительных отраслях, таких как банковская, медицинская, онлайн-ритейл, электронная коммерция и другие.
Например, предполагается, что злоумышленникам удается изменить DNS-записи и IP-адреса для Amazon. Затем они направляют запрос на другой сервер с поддельным IP, который контролируют или принадлежит злоумышленникам. Любой человек, пытающийся получить доступ к подлинному сайту Amazon, будет перенаправлен на неправильный адрес, который может содержать вредоносные программы для кражи конфиденциальной информации.
Кроме веб-сайтов, злоумышленник может вставить поддельный адрес для сервера электронной почты или других веб-приложений, таких как банковские приложения.
Поскольку изменения в DNS регулярно распространяются с одного сервера на другой, отравленный кэш может распространяться на другие DNS-серверы и системы, что приводит к большому ущербу. Например, поддельная запись может быстро распространяться на другие машины, такие как DNS-серверы Интернет-провайдеров, которые затем будут хранить ее в своем кэше. Отсюда он распространяется дальше на оборудования пользователей, такое как браузеры, мобильные телефоны и маршрутизаторы, которые также будут хранить поддельную запись в своих кэшах.
Как работает атака отравление DNS-кэша?
Преступники могут отравить кэш DNS с помощью различных методик.
Во время обычных операций DNS-запросы хранятся или кэшируются в базе данных, которую пользователи веб-сайтов могут запрашивать в режиме реального времени. Как правило, база данных DNS содержит список имен Интернета и соответствующих IP-адресов. И это облегчает поиск и доступ к веб-сайтам с использованием имен в отличие от IP-адресов, что может быть очень сложным и запутанным.
Например, без системы DNS пользователям потребуется запомнить строку чисел, составляющих IP-адреса для всех веб-сайтов, которые они хотят посетить.
К сожалению, DNS имеет несколько недостатков в безопасности, которые злоумышленники могут использовать и вставлять в систему поддельные записи адресов интернет-домена. Обычно преступники отправляют на DNS-сервер поддельные ответы. Затем сервер отвечает пользователю, сделавшему запрос, и одновременно законные серверы кэшируют поддельную запись. Как только сервер кэша DNS сохранит поддельную запись, все последующие запросы на скомпрометированную запись получат адрес сервера, управляемого злоумышленником.
Отравление DNS-кэша в целом состоит из внедрения поврежденных записей в базу данных кэша сервера имен, и злоумышленники используют различные методы. К ним относятся:
Когда пользователь веб-сайта или веб-приложения отправляет запрос на определенный домен через браузер или онлайн-приложение, DNS-сервер сначала проверяет, существует ли запись в кэше. Если он не сохранен, он запросит информацию у авторитетных DNS-серверов, а затем ждет ответа. В течение некоторого времени злоумышленники будут использовать этот узкий период ожидания, временно брать на себя роль исходного DNS и выдавать поддельный ответ до того, как авторитетный сервер отправит подлинный адрес. Однако, поскольку период ожидания обычно очень короткий, показатель успеха очень низкий.
Другой способ включает отправку поддельных ответов от DNS-сервера, олицетворяющего легитимный. Поскольку проверка DNS обычно не выполняется, злоумышленники могут подделать ответ от DNS-распознавателя по мере запроса сервера имен. Это также становится возможным благодаря тому, что DNS-серверы используют протокол пользовательских датаграмм (UDP) вместо TCP. Обычно связь DNS небезопасна из-за незашифрованной информации в пакетах UDP и отсутствия аутентификации. Это облегчает злоумышленникам вставлять в ответы поддельные адреса.
Уязвимости DNS используемые злоумышленниками
Уязвимости безопасности в определенных веб-приложениях, а также отсутствие надлежащей аутентификации DNS-записей позволяют киберпреступникам легко скомпрометировать ответы DNS и остаться незамеченными. Некоторые из этих уязвимостей включают в себя:
Отсутствие проверки и валидации
DNS имеет первую структуру доверия, которая не требует проверки IP-адреса для подтверждения его подлинности перед отправкой ответа. Поскольку DNS-распознаватели не проверяют данные в кэше, там остается неверная запись, пока она не будет удалена вручную или не истечет срок действия TTL.
Уязвимость рекурсивного DNS-сервера
Когда рекурсивный запрос активен, DNS-сервер получает запрос и выполняет всю работу по поиску правильного адреса и отправке ответа пользователю. Если у него нет записи в кэше, он будет запрашивать ее у других DNS-серверов от имени клиента, пока не получит адрес и не вернет его пользователю. Включение рекурсивного запроса представляет уязвимость безопасности, которую злоумышленники могут использовать для отравления кэша DNS.
Поскольку сервер ищет адрес, он предоставляет злоумышленнику возможность перехватить трафик и предоставить поддельный ответ. Затем рекурсивный DNS-сервер отправит ответ пользователю и одновременном сохранит поддельный IP-адрес в кэше.
Отсутствие шифрования
Как правило, протокол DNS не зашифрован, и это облегчает злоумышленникам перехват его трафика. Кроме того, серверы не должны проверять IP-адреса, на которые они направляют трафик, следовательно, они не могут определить, является ли он подлинным или поддельным.
Как предотвратить DNS спуфинг?
Мониторинг данных DNS в реальном времени может помочь установить наличие в трафике необычных шаблонов, действий пользователей или поведения, таких как посещение вредоносных веб-сайтов. И хотя обнаружение отравления DNS-кэшем затруднено, существует несколько мер безопасности, и компании и поставщики услуг могут принять меры, чтобы предотвратить это. Некоторые из мер, предотвращающих отравление DNS-кэша, включают использование DNSSEC, отключение рекурсивных запросов и многое другое.
Предельный уровень отношений доверия
Одной из уязвимостей DNS-транзакций являются отношения высокого доверия между различными DNS-серверами. Это означает, что серверы не проверяют подлинность получаемых ими записей, что позволяет злоумышленникам даже отправлять поддельные ответы со своих нелегитимных серверов.
Чтобы злоумышленники не использовали этот недостаток, группы безопасности должны ограничить уровень доверительных отношений, которые имеют их DNS-серверы с другими. Настройка DNS-серверов таким образом, чтобы они не опирались на доверительные отношения с другими DNS-серверами, затрудняет использование киберпреступниками DNS-сервера для компрометации записей на законных серверах.
Существует множество инструментов для проверки наличия угроз безопасности DNS.
Использование протокола DNSSEC
Расширения безопасности системы доменных имен (DNSSEC - Domain Name System Security Extensions) используют криптографию с открытым ключом для подписи DNS-записей, поэтому они добавляют функцию проверки и позволяют системам определять, является ли адрес законным или нет. Это помогает проверять и аутентифицировать подлинность запросов и ответов и тем самым предотвращать подделку.
При обычной работе протокол DNSSEC связывает уникальную криптографическую подпись с другой информацией DNS, такой как записи CNAME и A. Затем DNS-распознаватель использует эту подпись для проверки подлинности DNS-ответа перед отправкой его пользователю.
Подписи безопасности гарантируют, что ответы на запросы, которые получают пользователи, проверяются законным исходным сервером. Хотя DNSSEC может предотвратить отравление кэша DNS, он имеет такие недостатки, как сложное развертывание, предоставление данных и уязвимость перечисления зон в более ранних версиях.
Не уверены, что в вашем домене включен DNSSEC? Немедленно проверьте с помощью инструмента DNSSEC Test.
Используйте последние версии программного обеспечения DNS и BIND (Berkeley Internet Name Domain)
BIND версии 9.5.0 или выше обычно имеет расширенные функции безопасности, такие как криптографически безопасные идентификаторы транзакций и рандомизация портов, что помогает минимизировать отравление DNS-кэша. Кроме того, ИТ-специалисты должны поддерживать программное обеспечение DNS в актуальном состоянии и гарантировать, что оно является самой последней и безопасной версией.
Помимо вышеизложенного, ниже приведены другие эффективные способы или практики предотвращения отравления DNS-кэшем.
Настройка DNS-сервера для ответа только информацией, относящейся к запрошенному домену
Убедитесь, что на сервере кэша хранятся только данные, относящиеся к запрошенному домену
Принудительно использовать сети IP для всего трафика
Отключить функцию рекурсивных запросов DNS
Заключение
Отравление кэш-памяти DNS приводит к перенаправлению пользователей домена на вредоносные адреса. Некоторые серверы, управляемые злоумышленниками, могут обманывать ничего не подозревающих пользователей, которые загружают вредоносные программы или предоставляют пароли, информацию о кредитных картах и другие конфиденциальные личные данные. Для предотвращения этого важно использовать передовые методы обеспечения безопасности.