Редактирование: СБ, 03 лекция (от 14 марта)

Материал из eSyr's wiki.

Версия от 10:17, 20 марта 2011; 212.192.253.132 (Обсуждение)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)

ПРЕДУПРЕЖДЕНИЕ: Вы редактируете устаревшую версию данной страницы. После сохранения страницы будут потеряны изменения, сделанные в последующих версиях.

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

== Практические аспекты сетевой безопасности. Уровень приложений ==

Когда веп лучше чем впа? Используя незащищённые механизмы граздо проще отстоять свою невиновность при обвинениях в распространении нелегального контента, например.

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

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

Есть ряд очень известных приложений, для которых выделены спец номера портов тцп и удп и специальная база IANA. То есть для каждого протолкоа который распрстранен более менее широко можно найти стандартный номер порта.
* 80
* 1443
* 25

Значит ли это то если вы просканируете мшину и увиите открытый 25 порт, что это смтп сервер? Нет не значит.

Всегда ли можно любой сервис повесить на любом порту? Что должно быть чтобы приложение могло забайндится на 25ый порт? Есть привелигрованные порты, до 1024, которые ос не даст анять без административных прав. Чтобы занять 25ый порт нужно чтобы пользователь от которого запускается сервис имел достаточно прав.

Условно все протоколы у п можно разделить на 2 класса -
* сервисные. предназанчены для обслуживания инфраструктуры. например днс. многие из протколов верхнего уровня в тцп рассчитаны на то что с другой стороны может сиеть человек. Собственно таким будет задание. Это значит что протокол используют аски кодировку и имеют четко выраженные команды, которые мнемонически понятны людям. Если возьмём хттп -- у него будут методы, которые имеют мнемонические названия. Кто угодно может прийти на соотв порт , ввести туда эту комманду и получить ответ в читаемом виде. Поэтому разделение на сервсиные и контентные протколы условно.
* контентные  непосредственно используются пользователями или придожениями чтобы получать то что нужно пользователям -- ексты картинки итд.

Сегодня будем говорить про днс смтп и хттп. Есть стандартизованные некоторые протколы которые бинарные в своей основе, то есть уиспользуют условно нечитаемые команды для взаиможейстявия между сущностями, но их очень мало. Всё что происходит на вашем канале на сетевом интерфейсе когд вше по взаим с удаленными узлами можно видеть буквальноглазами запустив соотв снифер. Рекомендую всем попробовать установить сниыер запустить и поиграться. Для большинста систем давно уже есть wireshark. Это навороченный снифер анализатор проттоколов с граф интерфейсом и большой библиотекой проотолколв. Есть другие средства -- tcpdump, snoop. Специф сниферы для отдельных типо проотколов, вылавливают только парольную информацию например dsniff. Но интересней смотреть на непосрдественно то что лежит в трафике и пользовать сниферы общего назначения. ВСё что происходит в сети мы можем видеть  снифере.

Демонстрация варшарк. Кроме трафика хттп мы модем много чего ещё -- ssdp. Можем посмотреть на хттп сессию буквально глазами. Follow TCP session. На этом экранчике мы вилим что есть цепочка тцп сегментов, которая относится к какому то хттп запросу. Пакеты уходят на сервер который обрабтывает зпросы.
Запросы-ответы кк-то рзбиты. Если смотреть на тца сегмент в сыром виде можно посмотреть мак, ип, и все то что описывается в лекциях и интересных картинках про формат заголовка ип здесьможно увидеть в живом пакете. Можно реконструировать вс. сессию в опр вида документ текстовый. Здесь видно что был отдан запрос get contents проткола версия такому то хосту и получили от сервера ткой то response  ну и дальше собственно текст. Тким образом можно внимаетьно изучать то что происходит у вас на канале. Рекомендуб каждому попробоват что-нибудь подобное. 
Возвращаясь к днс. В протоколе ип организована глобальная адресация. То есть каждый узел имеет свой уник ип адрес. Всего 32 бита на адрес ип в4 то есть если на какой то машине требуется взаимодействовать с большим количеством других адресов нужно где то хранить большие списки адресов и отмечать чего чему соотв, какие сервисы запщены. Символьные адреса появились сразу как только был сделан стек протоколв. Первоначально просто записывались файлы соотв ип адреса символьному имени и сейчас до сих пор это сохранилось и можно пользоваться/. В /etc/hosts можно хранить записи вида

127.0.0.1 localhost #есть по умолчанию

192.168.10.1 www

В любой современной ос есть библиотека и набор программ отвечающий за разрешение имен. Днс не единственный источник. етц хостс не имеет отношения к днсу никакого. Днс -- один из источноиков данных про соотв символьных имен и ип адресов. Система днс представляет собой распр базу данных, распр по большому колву узлов. База не просто распр, она еще и иерархическая. Если вы вспомните ккой формат имеет символьное доменное имя -- это набор буковок разделённых точками. Точки -- спец символы для разделения уровней доменных имен. Бывают домены первого уровня, второго , третьег. Считается с конца.. Чем выше номер -- тем ближе к правой(????) части.

Первоначально у  ткой иерархии есть корень, точка от которой отсчитываются доменныие имена. Какой корень в днсе?

Просто точка.

ya.ru эквив ya.ru.

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

Резолвер в ос это то клиент который обается с системой днс. Он умеет брать инф ещё и ряда источников. Этот резолвер можно настрить 2 способами. В линуксе файл /etc/nsswitch.conf .Тут же указывается прядок обхождения известных хранилищ. Перезапись хостс делают многие трояны сопровождающие фишинговые сайты.

в /etc/resolv.conf можно указывать суффиксы для имен, ип адрес днс сервера. Еси вы сечас находитесь дома то скорей всего там будет адрес днс сервера провайедра. Или это будет локалный нейм сервер компании. Сейчас мало нсов пускают к себе кого угодно.

Если наш резолвер увидел у себя в нссвитче запись хост днс, то резолвер поподставляет разные суффиксы и поспрашивает локальный неймсервер. Локальнй неймсервер отдаст адрес если он авторитетнет для зоны, в которой лежит имя. 
Слайд с форматом записей о зонах bind а. Демон named. Формат это й таблицы соотв один в один тому что ходит в запросах днс. Формат кк вы видите текстовый все записи сделаны в терминах ресурсов. Днм база хранит в сеье ресурсные записи. Запись может иметь тип. Наиболее часто используемый тип адрес, обознаается A. Это просто соотв символьного имени ип адресу. 
Есть другие типы. ns-говорит кто является авторитетом или слейвом неймсервром для записи. ну и самая главая SOA -- запись о самой зоне. Перечисляются параметры важные для зоны. ыУКШФД ТГЬИУК  -- инкреминтируется при каждомизменении. Таймауты для некоторых действий. Рефреш -- таймаут с которым другие сервера должны обновлять информацию об этой зоне. Этот парметр испоьзуется кэшами резолверов чтобы знать сколько времени можно доверять информации об этой зоне. Чем меньше значение тем выше нагрузк на сервер. Но иногда маленькое время полезно. Например чтобы каждый новый клиент или кждый новый запрос повторно уходил в днс для того чтобы распределять клиентов по всему ботнету и чтобы нельзя было отследить откуда приходит информавция. Нижний таймаут эша у резолвера толи 10 то ли 30 минут. Еще там есть префикс ин который говорит о сети. Предполагается что базу днс можно хранить ещё для разного. ин говорит что это интерент. MX говорит о том, кто является мейл хостом для зоны.
Всё это можно смотреть вручную в линуксе есть nslookup. у байнда есть командочки host, вшп. dig дает побольше, читать его поинтересней.

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

Специф атаки на днс направлены на подделку записей в кэшах.. Было несколько уязимостей в том числе в байнде. днс еализован через удп. Вы не можете проверить кто реально являлся источником ответа. Можно было использовать спец сформированныые ответы. Например хоите отравить кэш насчет яндекса или мейл ру. Вы поднимете своё зеркало мейл ру у себя и атакуете днс кэши той сети клиентов которой хотите поколлектить. Вы формируете специальные ответы на днс запросы, которые всевозможного вида и этими ответами бомбардируете нс атакуемой сети. Когда нибудь ам повезёт и совпадёте по врмени с тем что какой то клиент спрсил этот адрес, а ваш ответ успел раньше чем ответ авторитетного нса. клиент попадет на ваш сайт и перепробует все свои пароли.

Защита появилась в 2009 2010 годах. Рандомизация номеров портов для запросов и дополнительная проверка о том что информация полностью соотв запросу.

Расширение днс dnssec ответы можно подписывать эцп. Недостатки -- необходимость организации pki. dnssec рзвернули на корневых серверах. сделать его глобальным хотя бы до 3его уровня доменных имен не очень реально. Есть хорошая новость -- одновременно с этим в 2010 году были стандартизованы гостовские криптоалгоритмы, прежде всего для днссека. Сейчас гост есть в опенссл

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

Электронная почта. Нас не интересует кк она организована. Если для отправки используется смтп, то для получения поп3 или имап4. смтп -- 80ые годы, плейнтекст, все такое. Отправка почты может и не поддерживат авторизации. для принятия сразу надо авторизовывать. поп3 и имап4 авторизация велась по ролям передаваемым в открытом виде. Если вы поднимите у себя любой тестапп и попробуете скачать почту по поп3 без старттлс то увилите свой пароль. и увидят все у кого запущен снифер на пути между вами и сервером. в смтп можно обойтись без аутентификации и авторизации. Отстутствие авт привело к тому что нельзя нормально реализоват фильтрацию сообщ на этапе отправки. Это всё привело к тому что со спамом борться очень сложно и делется это на стороне клиентов, то есть тех серверов что являются конечноыми при отправке почты. С смтп тоже придётся поэкспериментировать. Еще одно -- чтобы отправить почту вам необязательно говорить от кого она, достаточно сказать кому. 
Упражнение. Пообщатся с вашим почтовым сервером по протоклу смтп, отправить письмо, хорошо бы подписанное пгп но с подделанными адреами.

MIME все эти протолы работают с кодировкой аски. а нам хочется и умляуты и картинки. Эта проблема адресуется стандартом майм. майм используется и в том же хттп. майм это способ кодирования произваольного формата данных про которые он знает в тот вид которым его можно передавать в хттп или смтп. спользуется кодирование base64. Можено поизучать приходящие вам письма и смотря какие используются типы майма. Всё это делается легко и пэтому легко делать спамботов.

Хттп. хттп базировался на хтмле, всё богатство и солложность были закопаны в контенте. он оказался очень лёгким с минимумом накладных расхходов, очень легким в реализации.

Протокол без состояний. Сервер не помнит ничего про точто вы раньше к нему приходили. Вся информация запрос-ответ. хттп работает при помощи команд которые называются методы
* HEAD
* GET
* POST

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

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

=== Форматы данных ===

хтмл надеюсь все знают.

хмл/json.

Основной недостаток хтмля -- избыточность наладных расходов. Процент избыточной информации может доходить до 99%. Например если вы талатнливо упаковывает векторы для системы машинного обучения в хмл. Жсон полегче. Родился из жаваскрипта. Чисто по формату он попроще и хуман ридбл. Формат его виден на рисунке.

Рекомендую поинтересоваться nfs -- сетевая файловая система. Очень редко когда встречается раздача нфса в интернет. но часто нфс серверы светятся на чтение кому гуодно. в частности солярис 8 делала по умолчанию именно так. Всемумиру был открыт партишн, который раздавался по нфс.

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

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

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.name/wiki/%D0%A1%D0%91%2C_03_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_14_%D0%BC%D0%B0%D1%80%D1%82%D0%B0%29