Подбираемся к вопросам безопасности. Мегаупрощенное введение.
Для начала не стоит забывать, что безопасность это штука как минимумм двоякая. Боюсь дать хорошее определение, н в любом случае речь идет о жвух вещах сразу, о надежности и о секретности.
Вопросы надежности сети, в особенности интернета очень интересны, и этим также занимаются в большом объеме, мы поговорим об этом немножко.
Интернет сам по себе не надежен. На разных уровнях ддля контроля целостности используются контрольные суммы. В случае tcp контролируется целостность потока.
Еще бывает так, что бац и отваливается кусок интернета. Буквально вчера из офиса лектора был недоступен сайт федоры. Трейсрут гуляет по европам, потом приходит в америку, и там теряется. В чем проблема? В том, что тамошние маршрутизаторы плохо нарисовали карту достижимости, прожевав протокол маршрутизаторышрутизации.
Повышение связности является решением этой проблемы и протоколы, которые отслеживают связность.
Хотелось бы быть уверенным в том, чтобы соответствующая пропускная спосбоность была бы достаточно чтобы передавать эти данные.
Задача гарнтированной пропускной способности может решаться двумя основными способами:
- оверпровайжонинг. нуден килобайт, резервируем мегабайт. Примерно так обыно и делается, несколько порядков. Хотя в силу природы интернета даже это ничего не гарантирует. Сколько порядков -- зависит от цены вопроса.
- внедрить некую информацию о желаемых параметрах прямо в сетевой протокол. Это немножко из серии мечтателей. Но можно разработать протоколы и соответствующие им условия использования, чтобы можно было что-либо гарантировать. В частности такое есть в ipv6. Мы с вами сталкивались с проотолоклом ecm -- когда маршрутизатор предупреждает предыдущий маршрутизатор о том, что канал перегружен.
Что такое секртеность? Это защита данных от разного рода атак на них. Тут возникает два вопроса, как мне кажется слегка отвязанных друг от друга.
- аутентичность данных -- как понять, что то что нам прислали, прислали те самые люди.
- безопасность самих данных.
Атакой может являться много что, вплоть до непреднамеренного форматирования винчестера. Мы должны смотреть на то, что у нас испортилось, а с другой стороны на то, что у нас скомпрометировалось.
Самый простой способ и самый широкий в охвате это ситуация когда злоумышленник не имеет представления что за данные он портит, потому что атакует он устройства которые порождают данные или передают.
Атака типа dos, когда злоумышленник делает так, чтобы наш сервис не работал.
Идея в том, что злоумышленник не имеет отношения к тем данным, которые портит.
Другая атака -- подмена данных, без узнавания исходных. Митник прославился тем, что проник в сеть сан микросистемс. У них из одного рута можно было сделать рсх на другую машину сразу в рут. атака базировалась
- на том, что реализация тцп в тогдашнем саносе следующий секвеншал намбер можно было предугаать. Он ждал, пока кто-нибудь будет делать рсш, давил его синфлудом и пытался имитировать то соединение.
Итак, трансляция фальшивых данных может привдить к любым последствиям, в том числе и к атакам типа изменил данные, стер данные.
Последние виды атаки, когда акующий получает доступ на чтени данных или вообще на модификацию
Если была возможность модификации, то под подозрением все подверженные данные, потому что вы не знаете, где и как установлена закладка.
Список для двух целей -- даже с точки зрения чисто технической соблюдение иформационной безопасности не является стройной теорией. Например объектом атаки может являться сам пользователь лично -- запудрить ему мозг и он сам все сделает. Типичный пример -- фишинг.
Второе зачем -- чтобы было понятно, что даже какие-то вещи которые кажутся самыми безопасными (10 сек не устаналвивалось соединение) могут быть опасными, как в случае с митником.
История, связанная с тем, как в сетевых протоколах вообще появлялось понятие об их безопасности
Когда делался уровень ноль, ни о какой защищенности сетевых протоколов речи даже не шло. telnet, rsh, pop, ftp.
В эти благословленные времена никто не задумывался что передача данных требует секртености, радовал сам факт передачи.
Но уже тогда было понятно, что уровень защиты данных, которые вы передаете по сети вообще говоря разный. Одно дело передача файла и другое дело логин и пароль. Содержимое файла мало кого волнует, а вот ваш
- логин и пароль могут волновать некоторых людей.
Но университетская среда и дух кудесников в белых халатах не посзволил вовремя окститься.
В общем man dsniff , там несколько строк протоколов, которые передают учетные записи в открытом виде.
Потом до народа стало жоходить, что простейший тцпдамп показыавет логин-пароль.
Люди начинают изобретать доморощенные средства шифрования данных. htcp basic authoritahion -- security through obscurity -- наивные методы шифрования.
Ещеодин наивный метод шифрования -- клиент подключает к севреу, сервер высылает ему пароль, клиент начинает все им шифровтаь. Если вы не отследили весь трафик, вы предположительно не сможете расшифровать
- трафик. Если отследили -- сможете.
Доступ по x11 с mit magic cookie. Куки не пересылается а кладется в специальный файл, а клиент дожен иметь к нему доступ и его предъявить серверу. Когда он его показывает из процесса показа можно выковырять
- куки. Да и вообще вопрос как он его получает.
На следующем этапе стали использовать теорию шифрования и встраивать соответствующие штуки в проотоколы прикладного уровня.
В основном это было шифрование паролем.
Довольно быстро додумались до того, чтобы засунуть шифрование между траснпортным и сетевым.
pop, smtp так устроены, что внезапно с процессе диалога клиент может скаать start tls и установить безопасное соединение.
Если встраивать шифрование на прикладном уровне, необходимо изменять прикладной протокол. Кроме того возникают подробности реализации, что надо обращаться к сторонним билиотекам.
С другой стороны если мы шифруем на уровне сокета, то мы теряем возможность модифицировать параметры шифрования в зависимости от свойств прикладного проотокола.
Типичная ситуация -- если пользоваться tls по https, то вы заходите а вам говрят -- сертификат плохой, на другое доменное имя. Будете пользоваться? Почему так? Когда устанавливается соединеие между
- отправителем и получателем, мы знаем только ип. Если два сайта на одном ип мы не можем обоим сделать валидный сертификат.
А вот если встроить тлс выше, то мы можем показывать сертификаты в зависимости от домена.
Диффи-Хеллман-Маркель
Если вам нужно передать данные, в деле участвуют два ключа -- открытый и закрытый. Один для шифрования, другой для дешифрования. Ключи для шифрования раздаются тем, кто хочет писать.
Ривест-Шамир-Адлеман
Monkey-in-the middle
Два замечания.
Типичный способ атаки -- сам процесс безупречен, но вы должны убедится в аутентичности открытых ключей.
Как это обеспечить? Подписать их. Правда, получается сказка про белого бычка. На этом можно сделать бизнес по внедрению своих клюбчей в разные продукты и потом продавть подписывание этими верифицированными ключами. Verisign и ко делают как раз это. На этом начал делать деньги Майкл Шаттлворт.