UNИX, осень 2008, 09 лекция (от 26 ноября)
Материал из eSyr's wiki.
| Строка 1: | Строка 1: | ||
| + | * '''Диктофонная запись:''' [http://esyr.org/lections/audio/uneex_2008_winter/uneex_08_11_26.0.ogg диктофон в нагрудном кармане лектора], [http://esyr.org/lections/audio/uneex_2008_winter/uneex_08_11_26.1.ogg диктофон на кафедре] | ||
| + | |||
Лектор пытался узнать, что он забыл в прошлый раз. | Лектор пытался узнать, что он забыл в прошлый раз. | ||
Продолжаем тему транспортного уровня, с выходом в прикладной уровень. | Продолжаем тему транспортного уровня, с выходом в прикладной уровень. | ||
Версия 01:39, 28 ноября 2008
- Диктофонная запись: диктофон в нагрудном кармане лектора, диктофон на кафедре
Лектор пытался узнать, что он забыл в прошлый раз. Продолжаем тему транспортного уровня, с выходом в прикладной уровень.
В прошлый раз была мутная деталь, которая более прозрачной не стала. О различии адресов транспортного и сетевого уровня. Одно производится из другого, но не всегда однозначное соответствие имеет место. Иногда IP и порт совпадают, но в общем случае адресация различна.
Что осталось необговорено на транспортном уровне? Во-первых, на траспортном уровне даются различные гарантии. Мы помним, что TCP гарантирует надежную доставку. Даются гарантии, связанные с тем, что данные не потеряются, не испортятся и пр. Было бы неплохо добавить еще один вектор надежности — защита данных от подсматривания и фальсификации. Помимо надежности есть вопрос о защите. Рассмотрим SSL. Кроме того, свойство траспортного уровня идентифицировать поток данных. Есть NAT. Можно добавить рассказ о шейпинге трафика, но там много всего. Есть такая вещь, как netcat. Еще есть tcpdump.
Начнем разговор с защиты потока данных на траспортном уровне. SSL. Есть такая вещь, как сетевое программирование, есть на втором курсе. Есть сокет — дырка, в которую можно с одной стороны кидать данные, с другой стороны получать. Мы забываем про маршрутизацию и работаем просто с сокетом. Нельзя сказать, что tcp и сокет — одно и то же. Сокеты бывают разные. Есть две дырки, а что между ними — непонятно.
Идея SSL состоит в том, чтобы прикрутить к этим дыркам шифрование. Если не вдаваться ни в какие подробности, то тут можно было бы и закончить. Нужно передать данные о алгоритме шифрования, должен быть сам алгоритм шифрования. Зашифрованные сообщения должны циркулировать между абонентом и адресатом. Никаких дополнительных ограничений на транспортный уровень не накладывается. Прикрутили с обоих сторон дырки шифровальные машинки, на лету шифрующие сообщения, которые затем проходят через Интернет.
По ряду причин, по причине того, что должен произойти первичный обмен данными для шифрования. Кто передает пароль для шифрования? Если он открыт, получается как у Ильфа и Петрова (строго спрашивал у всех пропуск, а у кого не было, пускал так). Можно где-то хранить, но тут есть проблемы. Факт того, что мы передали кому-то пароль фактически значит, что пароль раскрыт. Решение в использовании двух паролей — один для шифрования, другой для дешифрования. Зашифровать так, как мы, никто не может.
Два способа применения: хотим засекретить данные, тогда всем раздаем открытый ключ, с помощью которого могут шифровать нам сообщение. Либо все могут прочесть, но никто не может сделать такую вещь, как мы.
Проблема все равно осталась. Нужно вначале раздать ключ, но как проверить подлинность выдавшего ключ? Нужно вначале еще как-то проверить, что именно тот адресат присал этот ключ. При асимметричном шифровании ключ выдается один раз. Приходим к сертификатам. Подпись Васи Пупкина, за которого ручается более мощный Вася Пупкин, который очень богатый и которого нельзя подкупить.
Шифрование SSL используется довольно часто. Все знают про https — протокол http, натянутый поверх ssl. Эта вещь связана с пресловутым обменом сертификатами. Редко кто занимается ручной первоначальной передачей сертификатов. Вряд ли кто-то вручную скачивал публичный сертификат.
Либо мы заходим на сайт, сертификат которого уже подписан. В нашей машине уже установлен корневой сертификат. Либо мы попадаем на сайт с самоподписанным сертификатом. Формально тут возможна фальсификация, потому что мы не знаем, что это именно тот, кто подписался. Но довольно редко передается очень серьезная информация. Чаще нужно просто защитить логин/пароль. Тут может быть самоподписанный сертификат, если мы уверены, что из-за такой мелочи не будут взламывать сеть всерьез.
Сейчас есть практика, когда нужно нажать на кнопку, подтверждающую, что мы ничего не боимся. Реально единственная возможность защититься — когда все пространство под единым администрированием. Если мы обращаемся к сети с другим администратором, мы увидим, что мы хотим, а он увидит, что он хочет.
Надстройка над транспортным уровнем означаем, что когда мы пользуемся прикладным уровнем, при использовании SSL на сокетах мы не сможем принять решение. Все они должны быть защищены одним ключом. Есть два сайта, расположены на одной машине с одним IP-адресом. Возникла идея осуществить сервис, защищенный SSL. Мы встаем перед неразрешимой проблемой. Осуществляется соединение к первому сайту (Вася Пупкин) по 443 порту. Соединение осуществляется по IP. На уровне SSL невозможно различить что-то на прикладном уровне. С одной стороны, упираемся в грамотное разделение прикладного и транспортного уровня. Но те люди, которые выписывают сертификаты, выписывают их на адреса прикладного уровня. Из двух сертификатов будет выбран только один. Будет еще более страшное предупреждение о том, что сертификат выдан другим людям. Неоправдано смешаны уровни. IP-адрес не отличается, порт не отличается, а отличается только доменное имя, являющееся частью прикладного уровня. TLS требует модификации протокола.
Программа stunnel. Предназначена для превращения протокола, незащищенного по SSL в протокол, защищенный про SSL. Есть сервис поверх telnet. Можем подключиться, ввести логин/пароль и работать. Можем предоставить Telnet с SSL. Не SSH, а просто защищенное соединение. stunnel осуществляет подключение к порту на удаленной машине. На транспортном уровне осуществляет шифрование. В качестве результата выдает на локальной машине порт, по которому служба уже расшифрована. Подключение к такому порту возможно обычным способом, потом stunnel переложит его в зашифрованный сокет и там уже будет делать всю работу по шифрованию за нас. На сервере может быть аналогичная ситуация. Мы можем не шифровать логин/пароль, а переставлять систему каждую неделю. Можно использовать stunnel. Он подключится по локальному порту к службе, делает зашифрованный порт на нашей же машине, к которому можно подключиться снаружи. Stunnel перекладывает из одного сокета в другой.
Telnet — волшебная программа, которую по назначению никто не использует. Можно сесть за свою машину, подключится к другой машине и работать с ней по сети. Это было чудесно в 80-х гг, а потом в 90-х или даже раньше, стало очевидно, что данные передаются в нешифрованном виде. Логин/пароль интересуют многих. Существует целый список протоколов прикладного уровня, которые передают данные в нешифрованном или плохо шифрованном виде. Сегодня telnet выжила не как терминальный клиент, а как протокол, с помощью которого можно подключиться, потыкать клавиши, получить что-то. Лектор может использовать telnet для отправки письма. Можно смотреть сайты, если в голове есть парсер html.
Реально лучше использовать netcat, например, в скриптах. С его помощью можно скачивать куски сайта. Преобразует сетевой трафик в что-то понятное. Простая программа. Можно передавать файлы. Бывает единственный способ, например, для передачи ssh-ключа. Превращает соединение в поток байтов. Что это за инструменты, подглядывающие пароль? Неужели пароль транслируется по всему Интернету? В одном режиме карта фильтрует лишние пакеты, в другом режиме принимает даже ей не предназначенные. В таком режиме можно принять чужие логин/пароль. Есть даже специальные утилиты для этого.
Утилита tcpdump же — вещь полезная. Она переводит карту в беспорядочный режим. Мы увидим не только фреймы ethernet, но и дешифровку трафика транспортного уровня. В иллюстративном плане tcpdump весьма полезен. Имеет даже некоторые прикладные протоколы.
Когда мы говорили про сетевой уровень и диапазонные адреса, говорили, что предусмотрены диапазоны адресов, не обязанные быть уникальными в масштабе Интернета. Если мы не хотим регистрировать все машины в сети, даже раскрывать машины в сети, можем использовать их. На самом деле такие машины могут ходить в Интернет, это повседневная практика — делать внутренние адреса и делать преобразование сетевых адресов. Можно посылать пакеты и, что важно, получать их. Есть машина, производящая трансляцию сетевых адресов. Есть абонент, посылающий пакет на сервер NAT, тот преобразует его адрес отправителя в свой. Все выглядит кристально, если не начать думать. У нас много машин с внутренними IP-адресами. Возможны варианты. У нас столько же внешних адресов, сколько и внутренних машин. Вопрос — зачем это нужно? Чтобы скрыть внутренний IP и с ним помухлевать. А так — практически, марушритизация, разве что адрес поменяли.
Реально же обычно внешний адрес один. Допустим, отправили пакет, получили ответ. Как понять, какой из внутренних машин предназначен ответ? Если пакет был частью TCP-трафика, мы не можем ничего понять. Введем таблицу. В таблице можно запомнить адрес транспортного уровня — отправитель-порт, получатель-порт. У нас ушел пакет, он — часть TCP-трафика, где известно 4 числа. Когда по TCP вернется ответ, отправитель и получатель будут поменяны местами. Храним IP внутренней машины, порт отправителя, IP сервера, порт сервера. Тогда, когда придет ответ, его можно идентифицировать по IP сервера и порту, увидеть в таблице запись о канале и передать по адресу.
Нужно однозначно выдавать порт сервера. Это просто — мы не сможем выделить один порт для двух каналов. Мы не анализируем состояние TCP. Ждем либо FIN, либо большого таймаута. Есть одна загвоздка — если внутри много машин, на всех может не хватить портов. Проблема червей, нерезанного осла. Раз несколько тысяч соединений, два несколько тысяч и адресное пространство кончается (65 тысяч).
На уровне IP есть ICMP. Там каждый запрос сопровождается уникальным номером-идентификатором. Когда придет ответ, будет понятно, на чей эапрос это ответ. На высоком уровне все проще.
Можем даже залезать на прикладной уровень, если протокол несложен. Пример — DNS-запрос. Посылается UDP-датаграмма, даже на транспортном уровне не можем определить. Заглянув внутрь, мы увидим, что это данные, соответсвующие DNS, по этому протоколу есть номер (кто, кому, номер запроса). Когда приходит датаграмма, подменяем данные и возвращаем клиенту.
Свойства транспортного уровня позволяют вытворять с потоками данных различные малоприличные штуки. Опознавать трафик и переставлять пакеты в зависимости от типа трафика. Один пакет от Васи Пупкина, другой от начальника. Принятый от начальника, пусть недавно, отправляем сразу же. Пакеты перераспределяются по приоритетам. Другой вариант — равные приоритеты. Нагрузка от абонентов разная, но пересылаем по одному пакету от абонента. Еще можно дропнуть один пакет умным маршрутизатором, если идет много больших пакетов. Тогда клиент произведет откат. TCP — довольно удобный инструмент для организации трафика, ограничения трафика и т.д.
Программа netcat, занимающаящася чем? Говорим ей порт, она подсоединяется, мы посылаем с клавиатуры текст, что-то происходит. Можно сделать программу listener'ом, тогда к ней можно подключиться и она выведет то, что ей пошлют. Можно отправить ответ с клавиатуры. Идея программы. Есть сервер, принимающий запросы, отправляющий ответы. Сервер пишем на shell. Нам лень программировать, читаем со стандартного ввода. Лень обрабатывать подключения, выводим на стандартном вывод. Программа-фильтр, по терминологии UNIX-систем. Запускаем программу командой server > file. Осталось сделать так, чтобы это работало с сетью, а не с вводом-выводом. Можно использовать netcat, но лучше использовать метадемон inetd. Он регистрируется в качестве listener на список заданных портов. Можно написать RPC-сервер. Обрабатывает одно подключение по порту, либо сколько угодно подключений на один порт. Преобразует сетевой трафик в поток UNIX, передает нашей программе. Так могут работать популярные ftp-серверы и другие программы.
Происходит жесткое разделение на транспортный уровень, за который отвечает inetd, и прикладной уровень, за который отвечает программа. Единственный недостаток — это существенно медленнее работает, чем когда работает сама программа. Все работает через канал. Канал нельзя забивать, иначе начнется непролезание. Это нагружает систему, если задача — сложная. Сервер http обычно через inetd не пишут. Популярный сервер получает много подключений, которые будут тормозить систему.
Inetd — юниксовый демон, большой пакет. Тип подключение — tcp-udp, какую программу запускать, с какими ограничениями. Например, сколько соединений в секунду разрешать, или сколько соединений с одного IP. В большинстве используется xinetd. Он умеет обрабатывать RPC-запросы. У него не один конфиг-файл, а много. Для каждой службы можно добавить один файл, а для удаления — удалить один файл. Позволяет не редактировать чужие файлы.
В книге Курячий-Маслинский есть описание, как за полторы минуты сделать сервис, выдающий календарь на текущий месяц.
Почему это переход к прикладному уровню? Демон xinetd никакого разбора не делает. Осуществляет работу на транспортном уровне.
Почему разговор о прикладном уровне? Приложений много и много протоколов. Но есть очень важный протокол. Без протокола DNS «не работает Интернет».
Конспект eSyr:
О различии адресов трансп. и сетевого уровня. На сет. уровне есть IP-адреса, на трансп. тоже. Одно явно произв. из другого, но не всегда однозн. соотв. имеет место. Там есть всякие жёствие зависимости, но в общем случае можно говорить о том, что есть адр. сетевого, есть адр. трансп., и это разные вещи.
На уровне тарнсп. даются всякие гарантии. То есть, мы помним, что TCP вроде бы нам гарантирует надёж. доставку, тем не менее, даются всевозм. гарантии, связ. с тем, что данные не потер., не исп. и так далее. Было бы важно подрисовать ещё один вектор надёжности: чтобы никто не подсмотрел и не подменил. Помимо собст. надёжности возн. вопросы зашиты. По этом поводу стоит рассм. SSL.
Именно свойство трансп. уровня, св-во уник. идент. поток данных приводит к тому, что возм. NAT.
Сюда можно прибавить общий рассказ о шейпинге. Приурочить его к тому, какие св-ва TCP-траффика как такового и как ими можно восп.
Наконец, можно потизноьку вылезать на ур. прикладной. Но для начала поговорить о netcat.
начнём с того, что имеет непоср. отношение, SSL. Все помнят сетевое программирование, програм. клиента, сервера. Есть спец. понятие сокет. Это такая дырка, котрорую можно приклеить одник концом к одной машине, а другую — к другой. Это та самая ситуация орг. транспорта, а просто исп. сокеты.
Есть такие сокеты, которые можно создать, подключиться и пересылать.
Идея SSL состоит в том, чтобы привинтить прямо к этим дыркам шифрование. Если не вдаваться ни в какие подробности, то на этом месте можно бы и закончить. Должен сушщ. некий алг., по которому они должны передать друг другу инф. о том, каой вид шифр. исп., должен сущ. механизм, который опред., какой вид шифр. исп., и должен суш. алг. шифрования, напр. по откр. ключю DSA. И доп. огр. на трансп. уровень не накладывается. Взяли дирку, прикрутили к ней шифровальную машинку, синхронно прикр. такую же с другой стороны и оно работает абс. прозрачно.
Можно только заметить, что на этом ур. не можем исп. типичный алг. шифр. по паролю. кто должен передавать пароль? Если этот пароль где-то записан, то мы должны передавать его все, с кем хотим зашифр. обмениваться, а что знают двое, знает весь мир. Посему зотелось бы исп. алг., когжа шифруем одним ключом, а дешифр. с помощью другого. И свой ключ никому не говорить. И это будет надёжно: все смогут наши данные читать, но никто не сможет его подменить. Другой вариант — когда зашифровать может кто угодно, а расшифр. можем только мы.
На самом деле от проблемы первонач. раздачи мы не ушли: мы должны раздать публичный ключ. Если мы исп. SSL, мы должны лругим способом обменяться ключами, чтобы увериться в том, что это именно этот адресат, после чего можно считать все сеансы связи рабоячими, пока ключ не просрочится.
Дальше начинаются разные упр. с сертификатами, это соотв. ключ и подпись удост. лица(?).
Идея ровно в этом: можно надеть поверхз трансп. уровня шифр. машинку.
SSL исп. довольно часто. Все знают волшеб. сочетание HTTPS это как раз HTTP с SSL. Для того, чтобы закр. эту тему, летор скажет две вещи:
- Никто, редко кто занимается ручной передачей публичных ключей. Ситуация обычно другая: вы заходите либо на сайт, который уже подписан, либо попад. на сайт, сертиф. которого вам не извесетен, скорее всего. он самоподписсан. Формально, здесь возм. фальсификация. Но довольно редко соед. с помощью SSL исп. для озраны денежной информации, ражи которой и городят такие вещи, как monkey-in-the-middle атаки и так далее. Чаще всего он исп. по прямому назначению шифр. соед, чтобы не передавать логин-пароль открыто.
Есть единстю случай, когда пляска с серт. актуальна: внутри корпорации.
Второе, что важно отметить: SSL — надстр. над транс. уровнем. Когда у вас исп. равноправные адреса рансп. уровня, вы не сможете принять решение, все они должны быть защищены одним и тем же ключом. И когда вы хотите защитить один из сайтов на одном IP ключом, то возн. неразреш. проблема нерзаличимости виртуалхостов на уровне TCP/SSL. Мы тут упираемся с одной стороны на грамотное разделение прикл. и трансп. уровня, с другой, сертификаты выпис. на адрема прикл. уровня. По этой причине SSL не всегда удобен.
Есть такая программа, называется stunnel, которая предн. для того, чтобы превращ. протокол незащищ. SSL, в протокол защищ. SSL. У неё два режима функц.: в режиме клиента и режиме сервера.
Может быть такая ситуация: у нас есть текстовый протокол, telnet, можете ходить, вводить логин-пароль и работать. Вы говрите, что не, несекьрно. Вам говорят хорошо, нсть тот же телнет, но защищённый SSL. Тогда вы поднимаете stunnel, и диндите его на другой лок. порт. Аналогичная ситуация в случае сервера: он может диндиться на порт и ретранслировать траффик. Фактически, это программная релазиация этой шифр. машинки.
Содержание |
netcat
telnet это такая программа, которую никто по прямому назнач. не использует.
В 80-х годах появилась возм. одить по сети к удалённым машинам по телнету, но довольно быстро обнаружилось, что это несекьюрно. И таких протоколов обнаружилось много.
Сейчас telnet созранился как средство, которое позв. подкл. по какому-то порту, что-то туда говорить и что-то получать.
Сейчас для этого есть netcat, у которого немного больше возм. Кроме того, у телнета есть протокол, который он пытается соблюдать, что не всегда удобно.
tcpdump
Вопрос, что это за люди такие, которые подгл. пароль? Он транслируется по всему интернету? Да нет, ещё с инт. уровня помним, что карточки могут работать в двух режимах: принимать только свои пакеты или все подряд. Сущ. даже утилиты, которые пост. мониторят сеть и если обн. пароль, то его записывают. Это не так нудно в норм. практике норм. человека, а вот утилита rcpdump вещь полезная, она как раз занимается тем, что переводит карточку в бесп. режим, и поск. он польз. дост. умной бибилиотеку, то вы увидите, не только езернетные фреймы, но и расшифр. разл. протоколов. Очень полезна в разл. адм. целях.
NAT
Когда мы гвоорили про сетевой уровень и про диапазоны адресов, говорили вот о чём, в частности: ipv4 и ipv6 предусм. спец. диап. адр., которые необяз. быть уник. в глобальном плане. Зачем это сделано, очевидно: если не хотите рег. машины в сети, ели не хотите раск. арз. сети, не хоите раскр. IP. Они при этом зам. могут общ. между собой.
Но при этом замеч. работает интернет, для этого есть NAT. В общем виде процесс ыгл. дост. просто: Есть машина, которая произв трансляцтю адресов. У неё есть внеш. IP, есть машина с внутр. IP. Посылает она пакет на IP сервера. Машина подм. адрес отпр. и посылает дальше. Всё замеч. пока не начинаем думать: хорошо, пусть трансляция 1 в 1, тогжа зачем это нужно? Разве что IP скрыть. А если внешних адресов меньше? Сервер ответил, кому он ответил? Задача неразреш., если не углуб. в трансп. уровень. Если этот пакет был частью TCP-трафика, то ... нужно хранить табличку, что посылалось, и какой ожид. ответ. Если отосланный пакет был частью TCP-трафика, то можем запомнить внутри TCP-пакета. Что можно запоминать:
- Адреса и порты отпр. и получателя. Осталось тогджа реализ. две вещи: анализ TCP-трафика и преобр. его .Второе — науч. выдаваться внешние порты. Т. о., для TCP так выглядит эта табличка. Эта штука называется Stateless NAT, посек. мы не анализир. сост. TCP, мы всего лишь запоминаем, что пакет ушёл. При этом может быть проблема, если порты кончатся.
- Что ещё модно делать, если считаем, что можно заглю внутрь. В протоколе ICMP каждый реквест сопровождается id, чтобы когда пришёл ответ, ыбло понятно, на чей запрос пришёл ответ.
- Можно также залезать на уровень прикладной. Если протокол несложный, то и с ним можно побаловаться. Наприсер, в случае с DNS. Саму по себе датаграмму нельзя проследить, но можно заглянуть внутрь, увидеть, что это DNS, запомнить и заманглить.
Сам NAt это не машинка из одной шестерёнки, которая может гляжеть на протоколы разных уровней.
tc
Свойства TCP позв. распозн., что за данные идут, и можно на соновании этого как-то трафиком управлять. Например, орг. очереди с приоритетами. Или например, стоит маршрутизатор, у которого начинает заканчиваться канал, и он начинает зарание дропать некоторые большие TCP-пакеты, чтобы они стали маленькими.
TCP — довольно удобный интр. для орг. огранич., приоритезации трафика.
Что-то, что прямиком подвед т к рассм. протоколов ур. прикладного
Мы сейчас говорили про netcat, которая занимается чем: подсоед. по сказанному порту, и позв. посыласть текст и получать его.
В серв. сарианте оно выглядит ещё смешнее: оно регистр. себя как сервер и когда ломятся на пор. порт, то рег. этот порт как рег. как станд. вывод.
Есть задача написать сетевой сервер: получать команды, обр. их и возр. на них ответ. При этом не хочется разбираться с сокетами. Тут пишется сервер на шелле или ещё чем, вместо этогол делается прочто чтение, вместо записи в сокет просто пишется станд. вывод. Эта прогр. в unix-терм. наз. фильтром. При этом она реализ. какой-то сетевой протокол, имеющийся или только что придуманный. Её замеч. тестировать: написать файл с командами и сказать server < file. Осталось здесать этот сервер сетевым. Можно устр. пляску с неткатами, но есть метадемон inetd. Он регистр. порты и орг. всё сетевое взаимод: указ. порты, огр. на количество инстансов и так далее. Многие сетевые серверы умеют работать inetd-режиме. В рез-те сетевой котовасией заним. inetd, а прикладной — ваша программа. Единст. довольно сущ. недостаток — это довольно медленно работает, сущ. медленнее, чем ситуация, когда на порту работает сама программа. Есть ещё xinetd, который ещё круче, и у него для каждого сервиса свой конфиг.
В книжке КМ есть пример того, как за полторы минуты сделать сервис, к которому подсоед. неткатом и видите календарь.
Почему это переход к прикл. уровню: inetd сам по себе никакого разб.прикл. уровня не делает, но ведёт себя так, как ведут себя больш. служб. прикл. уровня.
Почему вообщк будет разг. про прикл. уровень: есть как минимум DNS.
|
|
