Differences between revisions 4 and 20 (spanning 16 versions)
Revision 4 as of 2008-08-03 20:36:09
Size: 6698
Comment:
Revision 20 as of 2008-10-09 21:54:14
Size: 10197
Comment: No more illustration needed.
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Сегодня всякая сеть. Во-первых продолжение про безопасность, причём практическая. Хотели попробовать stunnel, ssh. Установим пакет stunnel командой `apt-get install stunnel`. Для этого, возможно, придется подключить дополнительные репозитории: stunnel не входит в состав ALT Linux Lite, но есть среди пакетов School Branch. Рассмотрим соответствующую программу "поближе". Stunnel, как указано в документации (man stunnel), может служить как клиентом, так и сервером при организации защищенного с помощью SSL туннеля. Отметим, что различные примеры использования stunnel можно найти на [[http://www.stunnel.org/ | сайте ]].
Line 5: Line 5:
Вспомним про stunnel и попробуем его настроить, чтобы показать, каким образом и почему SSL очень похож на протокол 6 уровня, уровня представления, ISO/OSI. В любом случае, реализация его полностью оторвана от прикладного уровня, в отличие от TLS, реализация которого встраивается в протокол прикладного уровня. Первый способ использования stunnel --- это запуск с клиентской машины для организации доступа к серверу, который принимает защищённые с помощью SSL подключения (например, некоторый клиент не умеет соединяться по SSL, а по тем или иным причинам необходимо использовать именно его). stunnel создаёт SSL-соединение с заданным сервером и открывает на клиентской машине специальный порт, к которому можно подключаться без SSL. При этом любые данные, отправленные по локальному соединению с созданным stunnel портом будут прозрачно для пользователя проходить на сервер через защищённое соединение. Вся работа с SSL при такой схеме осуществляется самой программой stunnel.
Line 7: Line 7:
Для начала установим этот пакет. Он не входит в состав ALT Linux Lite, но есть в школьном бранче. Stunnel это программа, которая может служить и клиентом, и сервером для организации туннеля, защищённого с помощью SSL, между клиентской и серверной машиной. При этом, с клиентской машины она организует доступ до сервера принимающего подключения https/imaps/ и шифрующего эти соединения по SSL, а со стороны клиента stunnel открывает порт, к которому можно подключаться уже без SSL. Использование stunnel состоит в том, чтобы подключение по закрытому каналу осуществлялось stunnel, а после того, как это подключение произошло, расшифрованный траффик представляется в виде ещё одного сокета на локальной машине, к которому можно подключится, не зная про ssl. Второй способ использования stunnel состоит в организации защиты для не умеющего использовать SSL сервера. stunnel в таком случае работает подобно простым сервисам, которые можно описать средствами xinetd, то есть, пропускает через себя данные опекаемого им демона как фильтр командной строки.
# я что-то не уверен насчёт современного imapd
Line 9: Line 10:
В качестве примера рассмотрим https://webmail.cs.msu.su/, где можно видеть "отпечатки пальцев", которые есть хеш-код публичного ключа. Конечно, если есть злоумышленник между вами и сайтом доверенным, то он может осуществить и такую операцию: не только подменить сертификаты, но и проанализировать и поменять хеш-код но самой странице, но вероятность подобного сильно уменьшается, поскольку злоумышленнику надо найти место на сайте, где ключ опубликован и подменять его в этом месте. Проиллюстрируем первый способ использования stunnel. Посмотрим на [[https://webmail.cs.msu.su/ | сайт]] --- web-интерфейс почтового сервера факультета ВМК МГУ. При подключении браузер обратит наше внимание на то, что соединение защищено с помощью SSL (в браузере Firefox, который входит в ПСПО, в адресной строке изменяется фон и появляется специальный значок):
Line 11: Line 12:
Почитаем man по stunnel. Там внизу нарисован второй способ использования stunnel --- в случае, если сервер не умеет организовывать нормальный ssl, а вам хочется шифровать соединение. Причём это серверы-фильтры, как в xinetd. И для организации ssl они просто вместо xinetd используют stunnel. {{attachment:../https_site.png}}
Line 13: Line 14:
На stunnel.org есть примеры. Указанные на сайте "отпечатки пальцев" --- это значения двух различных хэш-функций от публичного ключа сервера. Если просмотреть свойства сайта, то среди административных сведений об используемом сертификате мы увидим такие же отпечатки:
Line 15: Line 16:
Два параметра: -d, чтобы он работал в качестве демона, -r --- к какому порту присоединяться, потом двоеточие, номер порта. Обратите внимание на то, что можно использовать как числовые номера, так и символьные. Есть организация IANA, которая среди прочего регистрирует номера портов (например 443 это hhtps и тд.), и они хранятся в файле /etc/services. Вот например мы не используем 80 порт, так как там может стоять обычный web-сервер, и не используем 8080, так как он здесь тоже занят, и поэтому возьмем 8088. {{attachment:../https_site_properties.png}}
Line 17: Line 18:
Теперь мы можем зайти на localhost:8088 и увидеть то же самое. Зачем вообще такое нужно? Когда вы заходите на локалхост, считается, что подсмотреть трафик очень сложно, а те, кто могут, имеют рута на машине и тогда уже всё равно. Если такого нету, то есть, подсоединение осуществляется по сети в защищенном режиме, и никто ничего не увидит. Это совпадение и должно убеждать нас в том, что сайт "подлинный", иными словами --- что "разговаривает" с нами именно webmail.cs.msu.su. Конечно, злоумышленник может встать на пути между нами и доверенным сайтом и выполнить более сложную операцию: подменить не только сертификат, но и значения "отпечатков пальцев" на странице. Вероятность подобного, однако, значительно меньше: необходимо заранее найти место на сайте, где опубликованы соответствующие значения, и в дальнейшем при перехвате соединения фильтровать содержимое http-трафика, подменяя опубликованные "отпечатки" своими.
Line 19: Line 20:
Лектор посмотрит, как скрипт генерирует сертификаты, у него есть разные опции, в том числе подписывание, и может быть можно будет запустить его со стороны сервера, чтобы он преобразовывал 80-й порт в какой ещё. Попробуем использовать stunnel в режиме клиента. Посмотрим для этого в документацию и обратим внимание на следующие параметры:
Line 21: Line 22:
На чём часть про стуннель заканчивается... Лектор использовал stunnel, когда не было у imapd ssl, был с ssl только циррус, а он большой и страшный.  * -P --- каталог для хранения PID-файла;
 * -c --- работа в режиме клиента (первый из описанных нами способов использования);
 * -d --- работа в режиме демона и приём соединений на указанный порт;
 * -r --- адрес и порт сервера.

Пусть PID-файл хранится в нашем домашнем каталоге ~. Подключаться мы будем к машине webmail.cs.msu.su по порту https --- он имеет номер 443 (информация об этом хранится в файле `/etc/services`). В качестве локального порта укажем 8088: стандартный порт http (80) может быть занят обычным web-сервером, а порт 8080 в нашем случае используется web-интерфейсом конфигуратора Alterator.

{{{
$ /usr/sbin/stunnel -P ~ -c -d 8088 -r webmail.cs.msu.su:https
}}}

Поскольку мы указали программе stunnel работать в режиме демона, то она закроет стандартный поток ввода и перед нами снова окажется приглашение командной строки. Проверим, принимает ли теперь stunnel соединения. Воспользуемся для этого утилитой netstat. Нам понадобится список "слушающих" (ключ -l, listening) TCP-сокетов (ключ -t), причём удобнее использовать числовую форму (ключ -n, numeric) записи портов и Интернет-адресов. Главным для нас будет ключ -p, заставляющий netstat выводить PID и имя "слушающих" программ:

{{{
$ netstat -ltnp | grep stunnel
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp 0 0 0.0.0.0:8088 0.0.0.0:* LISTEN 4667/stunnel
}}}

Программа grep отфильтровала стандартный вывод netstat, оставив в нем лишь строку, содержащую слово stunnel (первые две строки были выведены в стандартный поток ошибок и поэтому не были отброшены). Как видно, stunnel успешно запустилась и принимает соединения на порту 8088 локальной машины.

Если мы теперь попробуем выполнить с помощью браузера подключение по адресу localhost:8088, то увидим обычный, "незащищенный" по мнению браузера сайт:

{{attachment:../https_site_stunnel.png}}

Зачем может пригодиться такая схема? В результате наших действий незащищенное подключение устанавливается только к локальной машине (localhost). Считается, что подсмотреть трафик в этом случае очень сложно. Те, у кого такая возможность есть, обычно обладают "полноценными" правами суперпользователя на данной машине, а значит, имеют практически неограниченные возможности обхода любой защиты. Если же этот вариант исключить, то останется лишь "подсматривать" внутрь защищённого SSL подключения по сети, что в большинстве случаев совершенно бесполезно.
Line 29: Line 56:
|| 0  || 1 || 1 || 1 || || 1 || SergeyKorobkov, DmitryChistikov, MaximByshevskiKonopko || || || || 90 || 1 || 1 || 1 || || 1 || SergeyKorobkov, DmitryChistikov, MaximByshevskiKonopko || || ||

Практика использования stunnel

Установим пакет stunnel командой apt-get install stunnel. Для этого, возможно, придется подключить дополнительные репозитории: stunnel не входит в состав ALT Linux Lite, но есть среди пакетов School Branch. Рассмотрим соответствующую программу "поближе". Stunnel, как указано в документации (man stunnel), может служить как клиентом, так и сервером при организации защищенного с помощью SSL туннеля. Отметим, что различные примеры использования stunnel можно найти на сайте.

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

Второй способ использования stunnel состоит в организации защиты для не умеющего использовать SSL сервера. stunnel в таком случае работает подобно простым сервисам, которые можно описать средствами xinetd, то есть, пропускает через себя данные опекаемого им демона как фильтр командной строки. # я что-то не уверен насчёт современного imapd

Проиллюстрируем первый способ использования stunnel. Посмотрим на сайт --- web-интерфейс почтового сервера факультета ВМК МГУ. При подключении браузер обратит наше внимание на то, что соединение защищено с помощью SSL (в браузере Firefox, который входит в ПСПО, в адресной строке изменяется фон и появляется специальный значок):

../https_site.png

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

../https_site_properties.png

Это совпадение и должно убеждать нас в том, что сайт "подлинный", иными словами --- что "разговаривает" с нами именно webmail.cs.msu.su. Конечно, злоумышленник может встать на пути между нами и доверенным сайтом и выполнить более сложную операцию: подменить не только сертификат, но и значения "отпечатков пальцев" на странице. Вероятность подобного, однако, значительно меньше: необходимо заранее найти место на сайте, где опубликованы соответствующие значения, и в дальнейшем при перехвате соединения фильтровать содержимое http-трафика, подменяя опубликованные "отпечатки" своими.

Попробуем использовать stunnel в режиме клиента. Посмотрим для этого в документацию и обратим внимание на следующие параметры:

  • -P --- каталог для хранения PID-файла;
  • -c --- работа в режиме клиента (первый из описанных нами способов использования);
  • -d --- работа в режиме демона и приём соединений на указанный порт;
  • -r --- адрес и порт сервера.

Пусть PID-файл хранится в нашем домашнем каталоге ~. Подключаться мы будем к машине webmail.cs.msu.su по порту https --- он имеет номер 443 (информация об этом хранится в файле /etc/services). В качестве локального порта укажем 8088: стандартный порт http (80) может быть занят обычным web-сервером, а порт 8080 в нашем случае используется web-интерфейсом конфигуратора Alterator.

$ /usr/sbin/stunnel -P ~ -c -d 8088 -r webmail.cs.msu.su:https

Поскольку мы указали программе stunnel работать в режиме демона, то она закроет стандартный поток ввода и перед нами снова окажется приглашение командной строки. Проверим, принимает ли теперь stunnel соединения. Воспользуемся для этого утилитой netstat. Нам понадобится список "слушающих" (ключ -l, listening) TCP-сокетов (ключ -t), причём удобнее использовать числовую форму (ключ -n, numeric) записи портов и Интернет-адресов. Главным для нас будет ключ -p, заставляющий netstat выводить PID и имя "слушающих" программ:

$ netstat -ltnp | grep stunnel
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp     0    0 0.0.0.0:8088     0.0.0.0:*         LISTEN       4667/stunnel

Программа grep отфильтровала стандартный вывод netstat, оставив в нем лишь строку, содержащую слово stunnel (первые две строки были выведены в стандартный поток ошибок и поэтому не были отброшены). Как видно, stunnel успешно запустилась и принимает соединения на порту 8088 локальной машины.

Если мы теперь попробуем выполнить с помощью браузера подключение по адресу localhost:8088, то увидим обычный, "незащищенный" по мнению браузера сайт:

../https_site_stunnel.png

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


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

90

1

1

1

1

SergeyKorobkov, DmitryChistikov, MaximByshevskiKonopko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080730/01Stunnel (last edited 2008-10-09 21:54:14 by MaximByshevskiKonopko)