Главная » Хабрахабр » [Перевод] Курс MIT «Безопасность компьютерных систем». Лекция 12: «Сетевая безопасность», часть 2

[Перевод] Курс MIT «Безопасность компьютерных систем». Лекция 12: «Сетевая безопасность», часть 2

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3

Вероятно, у вас имеется конфликт порядковых номеров всех этих соединений, которые вы получаете? Студент: возможно, у вас все еще есть проблема столкновения интересов, потому что вы могли бы задействовать 32 бита для адресов пиров и у вас имеется множество портов для каждого из них.

Так что если это разные порты, то они совершенно не мешают друг другу. Профессор: получается, что эти порядковые номера специфичны для IP-адреса и номера порта пары источник/назначение. Если говорить конкретно, порты имеют меньшие порядковые номера.

Студент: если порядковые номера являются глобальными, то не может ли атакующий попасть в соединение между другими клиентами?

На самом деле, если сервер увеличивает порядковый номер, например, на 64k для каждого соединения, вы соединяетесь с сервером, а потом с ним соединяются ещё 5 человек, и здесь можно организовать атаку. Профессор: да, это хорошее замечание. С другой стороны, вы могли бы, вероятно, сделать так, что пакет из последней строки S->A был бы доставлен непосредственно перед этим пакетом в первой строчке C->S. Так что в какой-то степени, вы правы, это немного хлопотно. Если вы посылаете свои пакеты друг за другом, есть хороший шанс, что они прибудут на сервер также один за другим.

Он будет другой, чем (SNs) во второй строке, но с порядковым номером, который следует сразу за ним. Сервер получит S->A и ответит этим порядковым номером (SNs). Но если вы тщательно расположите свои пакеты нужным образом, то сможете легко отгадать последовательность. И тогда вы будете точно знать, какой порядковый номер (SNs) следует вложить в третий пакет вашей последовательности.
Поэтому я думаю, что это не слишком надежный способ подключения к серверу, он основан на допущениях. Или, может быть, вы попробуете несколько раз, и вам повезет.

Это не слишком большое количество, верно? Студент: даже если номера генерируются совершенно случайно, вам нужно угадать один из 4 миллиардов возможных номеров. Я думаю, что в течение года вы, вероятно, сможете пробиться в эту сеть.

Вы не должны слишком полагаться на TCP в смысле обеспечения безопасности. Профессор: да, вы абсолютно правы. И вероятно, вы сможете отправлять в течение дня очень много пакетов, если у вас есть достаточно быстрое соединение. Потому что вы правы, это всего лишь 4 миллиарда догадок.

Мы никак не можем его обезопасить. Таким образом, у нас здесь имеется своего рода интересный аргумент по поводу ненадёжности TCP, потому что у нас имеется только 32 бита. Но я думаю, что множество приложений, которые в достаточной мере полагаются на этот протокол, вообще не задумываются о безопасности, и это действительно становится проблемой.

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

Давайте теперь посмотрим, почему плохо, если люди смогут подделывать TCP-соединения с произвольных адресов?

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

Раньше было так, что вы могли бы запустить что-то вроде rlogin для компьютера по адресу, скажем, athena.dialup.mit.edu. Итак, один пример, где это было проблемой, на сегодня эта проблема в основном решена, это использование семейства команд r, таких как rlogin. И данная операция будет позволена, поскольку все компьютеры в сети mit.edu заслуживают доверия, чтобы делать такие заявления. И если ваше соединение идёт от хоста MIT, тогда эта команда rlogin будет успешной, если вы скажете: «да, я пользователь Алиса на этом компьютере, позвольте мне зайти как пользователь Алиса на другой компьютер».

Это соединение использовало «Цербер» с самого начала. Я должен сказать, что у dial-up никогда не было этой проблемы. И это является примером использования IP-адреса в механизме проверки подлинности соединения, когда система проверяет, заслуживает ли доверия клиент, вызывающий сервер. Но другие системы, конечно, имели такие проблемы. Но полагаться на IP всё равно кажется явно плохим планом. Так что то, что раньше было проблемой, теперь ей не является.

С другой стороны, есть еще много других примеров протоколов, которые полагаются на авторизацию на основе IP-адреса. Сейчас rlogin уже не используется, недавно он был заменен безопасной оболочкой SSH, которая является отличным протоколом сетевого уровня. Когда вы отправляете электронную почту, вы используете SMTP, чтобы поговорить с некоторым почтовым сервером для того, чтобы отправлять сообщения. Одним из них является SMTP. Так, например, почтовый сервер Comcast принимает почту только с IP-адресов Comcast. Чтобы предотвратить спам, многие SMTP-серверы принимают входящие сообщения только с определенного исходного IP-адреса. Но у нас был, по крайней мере, один сервер, который не работал как нужно, используя IP-аутентификацию. То же самое для почтовых серверов MIT – они будут принимать почту только с IP-адресов MIT.

В худшем случае, вы отправите часть спама через почтовый сервер. Здесь всё не так уж и плохо. Так что, вероятно, поэтому они все еще используют rlogin, в то время как вещи, которые позволяют вам войти в произвольную учетную запись, перестали использовать идентификацию на основе IP-адресов.

Как допущение предположим, что какой-то сервер использовал rlogin. Итак, почему такой механизм аутентификации — это плохой план? Что плохого при этом может произойти? Что бы вы сделали, чтобы атаковать?

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

Он синтезирует данные, выглядящие как допустимый набор команд rlogin, которые говорят: «войдите как этот пользователь и выполните эту команду в моей оболочке Unix». Профессор: да, в основном злоумышленник захватывает компьютер.

Вы синтезируете эти данные data (SNc +1), монтируете всю атаку и отправляете эти данные, как если бы с клиентом rlogin взаимодействовал законный пользователь, и тогда вы можете действовать дальше.

Еще одна проблема — эти атаки сброса reset attack. Хорошо, это одна из причин, почему вы не хотите, чтобы ваши порядковые номера TCP можно было бы угадать. Точно так же, как мы могли бы отправить SYN пакет, если знаем чей-то порядковый номер, точно также мы можем отправить пакет сброса.

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

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

Если у вас есть множество роутеров, которые общаются между собой с помощью некоторых протоколов маршрутизации, то между ними имеются какие-то физические связи. В случае, когда маршрутизаторы «разговаривают» друг с другом, это предположение носит особенно критический характер. Фактически в каждой из этих физических связей, которые роутеры используют для обмена информацией о маршрутизации, запущен сеанс TCP. Но поверх этих физических связей они общаются по сетевому протоколу, который работает через TCP. Здесь используется протокол BGP, о котором мы поговорим позже.

Так что если происходит разрыв TCP-соединения, роутер считает, что связь разорвана и начинает пересчитывать все свои таблицы маршрутизации. Этот протокол BGP использует тот факт, что если TCP-соединение живо, то живо и физическое соединение.

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

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

Студент: если вы злоумышленник и хотите организовать целевую атаку против конкретного пользователя, не могли бы вы просто сохранить отправку запросов на подключение к серверу от имени его IP-адреса и заставить его сбросить соединение с сервером?

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

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

Здесь нет никакого доступа типа «Оракул». Таким образом, вы должны угадать изрядное количество вещей. Вот причина, почему это тоже не сработает. Вы не можете просто так запросить у сервера порядковый номер этого парня.

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

Это 8-битное поле, которое уменьшается на каждый маршрутизатор, чтобы убедиться, что пакеты не попадают в бесконечный цикл. Удачной реализацией разработчиков этих протоколов является замечательная область в пакете, которая называется „время жизни“, или TTL. Максимальное значение TTL равно 255 и далее уменьшается.

Они сбрасывают любой пакет со значением TTL, которое не равно 255. Итак, что делаю эти умные протоколы? И если противник пытается внедрить любой другой пакет в существующее соединение BGP, он будет иметь значение TTL меньше 255, потому что это значение будет уменьшено другими роутерами, расположенными вдоль пути маршрутизации, включая и данный роутер. Потому что, если пакет имеет значение 255, то он может прийти только от роутера на другой стороне данного соединения. Поэтому данный пакет просто будет отклонен получателем.

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

Студент: разве нижний правый маршрутизатор не отправляет что-то с TTL, равным 255?

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

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

Но в действительности разработчики были нацелены на это конкретное приложение, для которого атака сброса особенно критична. Другие исправления для BGP заключаются в реализации некоторой формы заголовка аутентификации, в том числе заголовка аутентификации MD5.

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

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

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

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

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

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

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

Так что это старый стиль ISN, скажем так. Таким образом, большинство реализаций TCP SYN все еще вычисляют этот начальный порядковый номер ISN так же, как мы вычисляли его раньше. То есть мы добавляем к нему функцию — что-то типа хэш-функции или SHA-1, или что-нибудь получше. И для того, чтобы на самом генерировать порядковый номер для любого конкретного соединения, мы добавляем к этому ISN старого образца случайное 32-х битное смещение.

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

На самом деле, вам придется угадать этот ключ, чтобы вычислить это значение. Но если у вас есть соединения из разных наборов источник/назначение, то нет ничего, что позволяет узнать точное значение порядкового номера другого набора соединения.

Вот таким образом большинство TCP-стеков решают сегодня эту конкретную проблему в области общих 32-х битных порядковых номеров. Я надеюсь, что ядро ОС сервера хранит этот ключ где-то в своей памяти и никому его не выдает. Это не слишком здорово, но оно работает.

Насчёт уникальности ключа… Студент: не могли бы вы повторить это еще раз?

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

Ранее мы рассматривали, что если вы получите порядковый номер для одного соединение A: A -> S: SYN (…), то после этого сможете сделать вывод о порядковом номере для соединения ACK (SNs). Единственная вещь, для которой нам нужен этот порядковый номер старого образца – это выбор алгоритма для предотвращения возникновения проблем с этими повторяющимися пакетами.

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

Студент: какой смысл включать в эту функцию ключ?

Я вычислю ту же функцию F, вычислю значение порядкового номера, затем вычислю функцию F для соединения, которое хочу подделать, и я угадаю, какой для этого будет первоначальный порядковый номер. Профессор: если вы не включите ключ, тогда я смогу с вами связаться.

Студент: так как машины теперь перезагружаются редко, можно ли попытаться подделать аутентификацию с помощью реверсивного…

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

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

Даже после того, как для TCP был реализован механизм смещения, был разработан другой протокол под названием DNS, который оставался чрезвычайно уязвим для атак подобного рода. С другой стороны, люди продолжают совершать одни и те же ошибки. UDP — это протокол без отслеживания состояния, когда вы фактически не устанавливаете соединение, в котором обмениваетесь порядковыми номерами. Причина заключалась в том, что DNS запускался через UDP – протокол пользовательских датаграмм. Сервер выясняет, каким должен быть ответ, и отправляет его обратно независимо от того, какой бы адрес источника не появился в пакете. В UDP вы просто отправляете запрос из своего источника к серверу. В результате этого было очень легко подделывать ответы DNS-сервера. Это маршрут по одному пути, в котором нет времени и возможности для обмена порядковыми номерами и установления того факта, что вы действительно общаетесь с правильным источником. Как же выглядит типичный запрос в DNS?

Предположим, клиент посылает DNS-серверу запрос C: C53 -> S53 на доступ к ресурсу mit.edu, обычно он принимается и отсылается через порт 53.

Далее сервер отвечает клиенту пакетом S: S53 -> C53 с названием запрошенного ресурса и его IP-адресом, и на этом всё заканчивается – соединение установлено.

Если я знаю, что вы пытаетесь подключиться к mit.edu, я просто отправлю много таких пакетов на ваш компьютер. Проблема заключается в том, что некоторые хакеры могут легко отправить подобный пакет ответа, делая вид, что этот пакет отправлен сервером, и здесь не так много случайностей.

Я точно знаю ваш IP-адрес, я знаю номера портов и я знаю, о чем вы спрашиваете. Я точно знаю, какой DNS-сервер вы собираетесь запросить. И если мой пакет попадает туда после того, как вы посылали свой запрос, но до того, как вы получили ответ реального сервера, ваша клиентская машина будет использовать мой пакет. Поэтому я могу просто указать здесь вместо IP-адреса ресурса mit.edu свой IP-адрес. Так что это еще один пример, где недостаточная случайность в протоколе позволяет очень легко инъецировать в соединение ответы или пакеты в целом.

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

Студент: нельзя ли это исправить путём включения некоторого случайного значения в клиентский запрос, которое позволяет серверу узнать, что это настоящий клиент?

Проблема, как мы уже упоминали, заключается в обратной совместимости. Профессор: это именно то, что сейчас сделали. Разработчики нашли всего 2 таких места. Очень сложно изменить программное обеспечение каждого DNS-сервера, поэтому очень трудно выяснить, в каком именно месте можно ввести случайность. Так что если вы можете выбрать номер порта источника случайным образом, то вы получите 16 бит. Первое — это номер порта источника, который использует 16 бит случайности. Внутри пакета есть идентификатор запроса ID, который также равен 16 битам, причём сервер не возвращает идентификатор запроса.

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

К сожалению, подобные проблемы возникают постоянно, хотя данный вариант защиты был разработан несколько лет назад.

Вместо того, чтобы полагаться на свойства случайностей небольшого количества битов в пакете, в DNS протоколах можно попробовать использовать шифрование. Я думаю, несколько в стороне существует другое решение этой проблемы DNS и обеспечения безопасности DNS на уровне приложений. Вместо того, чтобы полагаться на любые свойства безопасности на уровне сети, они требуют, чтобы все DNS-имена имели прикреплённые к ним подписи. Например, протокол DNS SEC, о котором кратко говорится в статье Стивена. Это кажется разумным планом, но оказывается, что проработка деталей на самом деле довольно трудоёмка.

В DNS вы хотите получить ответ, что это имя ресурса имеет этот IP-адрес, либо ответ: „извините, но такого имени не существует“. Одним из примеров обнаруженной проблемы является имя и источник происхождения origin. Так каким образом можно подписать ответ, что данного имени не существует ещё до того, как был послан запрос по поводу данного имени? Таком образом, вы также хотите подписать ответ, отрицающий существование имени, потому что в противном случае, атакующий может послать вам ответ, что данного имени не существует, даже если оно существует.

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

Он делает это, подписывая пробелы в пространстве имен. Протокол DNS SEC имеет умный механизм для подписания несуществующих имён, который называется NSEC. Например, NSEC может сказать, что раз есть имя foo.mit.edu, следующим за ним именем в алфавитном порядке будет goo.mit.edu, и между этими двумя именами не может быть ничего другого, расположенного в алфавитном порядке.

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

То есть он может запросить доменное имя, найти эту запись foo.mit.edu -> goo.mit.edu — >…. Однако это позволяет злоумышленнику полностью перечислить ваши доменные имена. Это даст ему ответ, говоря, каково следующее имя в вашем домене и так далее. и сказать: » отлично, эти два имени существуют, а теперь позвольте мне запросить имя gooa.mit.edu".

Сейчас там используется хорошая вещь под названием NSEC3, которая пытается решить эту проблему частично – кое-что вроде работает, кое-что не совсем. Так что на самом деле немного трудно придумать правильный протокол, который сохранял бы все хорошие свойства DNS и при этом предотвращал бы перечисление имен и другие проблемы.

52:00 мин

Лекция 12: «Сетевая безопасность», часть 3 Курс MIT «Безопасность компьютерных систем».

Полная версия курса доступна здесь.

Вам нравятся наши статьи? Спасибо, что остаётесь с нами. Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? Хотите видеть больше интересных материалов? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps до декабря бесплатно при оплате на срок от полугода, заказать можно тут.

класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки? Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] [Интересное из-за бугра] Как мы остановим технологическую зависимость?

Гайд, как вернуть время, которое у нас забирают наши девайсы. переводчика:Это скорее не гайд, а размышление на тему современной зависимости от смартфонов и приложений. Прим. Статье уже 11 месяцев, поэтому увидев фразу “недавно”, учитывайте этот факт.Статья была переведена из интереса ...

[] Граббер 2GIS в семь строчек кода, или почему важно контролировать лимиты запросов на сервер

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