Differences between revisions 12 and 13
⇤ ← Revision 12 as of 2008-08-03 23:54:51 →
Size: 7089
Editor: SergeyKorobkov
Comment:
← Revision 13 as of 2008-08-04 12:46:54 → ⇥
Size: 8353
Editor: DmitryChistikov
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Сегодня всякая сеть. Во-первых продолжение про безопасность, причём практическая. Хотели попробовать stunnel, ssh. Установим пакет stunnel командой `apt-get install stunnel` (для этого, возможно, придется подключить дополнительные репозитории: он не входит в состав ALT Linux Lite, но есть в школьном бранче) и рассмотрим соответствующую программу "поближе". Stunnel может служить как клиентом, так и сервером для организации защищенного с помощью SSL туннеля.
Line 5: Line 5:
Вспомним про stunnel и попробуем его настроить, чтобы показать, каким образом и почему SSL очень похож на протокол 6 уровня, уровня представления, ISO/OSI. В любом случае, реализация его полностью оторвана от прикладного уровня, в отличие от TLS, реализация которого встраивается в протокол прикладного уровня. В первом случае stunnel запускается с клиентской машины и организует доступ к серверу, принимающему защищенные с помощью SSL подключения. Она прокидывает к серверу туннель и открывает на клиентской машине специальный порт, к которому можно подключаться без SSL. Подключения будут автоматически защищаться SSL и пробрасываться на сервер (работу с SSL при такой схеме stunnel берет на себя).
Line 7: Line 7:
Для начала установим этот пакет. Он не входит в состав ALT Linux Lite, но есть в школьном бранче. Stunnel это программа, которая может служить и клиентом, и сервером для организации туннеля, защищённого с помощью SSL, между клиентской и серверной машиной. При этом, с клиентской машины она организует доступ до сервера принимающего подключения https/imaps/ и шифрующего эти соединения по SSL, а со стороны клиента stunnel открывает порт, к которому можно подключаться уже без SSL. Использование stunnel состоит в том, чтобы подключение по закрытому каналу осуществлялось stunnel, а после того, как это подключение произошло, расшифрованный траффик представляется в виде ещё одного сокета на локальной машине, к которому можно подключится, не зная про SSL. Второй способ использования stunnel состоит в организации защиты для не умеющего SSL сервера (pppd, imapd). Схема работы stunnel в таком случае напоминает использование xinetd, только в данном случае соединения принимаются программой stunnel (она берет на себя создание SSL-прослойки), которая выступает в роли фильтра.
Line 9: Line 9:
В качестве примера рассмотрим https://webmail.cs.msu.su/, где можно видеть "отпечатки пальцев", которые есть хеш-код публичного ключа. Проиллюстрируем первый способ использования Stunnel. Рассмотрим сайт https://webmail.cs.msu.su/ --- web-интерфейс почтового сервера факультета ВМК МГУ. При подключении к данному сайту браузер обратит наше внимание на то, что подключение защищено с помощью SSL, адресная строка при этом имеет желтый фон:
Line 11: Line 12:
Также можно посмотреть свойства сайта и увидеть там тот же хеш-код что и есть подтверждение подлинности сайта.
Указанные на сайте "отпечатки пальцев" --- это значения двух различных хэш-функций от публичного ключа сервера. Если просмотреть свойства сайта, то среди информации об используемом сертификате мы увидим такие же отпечатки:
Line 13: Line 16:
Конечно, если есть злоумышленник между вами и сайтом доверенным, то он может осуществить и такую операцию: не только подменить сертификаты, но и проанализировать и поменять хеш-код но самой странице, но вероятность подобного сильно уменьшается, поскольку злоумышленнику надо найти место на сайте, где ключ опубликован и подменять его в этом месте.
Line 15: Line 17:
Почитаем man по stunnel. Там внизу нарисован второй способ использования stunnel --- в случае, если сервер не умеет организовывать нормальный SSL, а вам хочется шифровать соединение. Причём это серверы-фильтры, как в xinetd. И для организации SSL они просто вместо xinetd используют stunnel. Это совпадение и должно убеждать нас в том, что сайт "подлинный", то есть с нами "разговаривает" именно webmail.cs.msu.su. Конечно, злоумышленник может встать на пути между нами и доверенным сайтом и выполнить более сложную операцию: подменить не только сертификат, но и поменять значение "отпечатков пальцев" на странице. Вероятность подобного, однако, значительно меньше: необходимо найти место на сайте, где опубликованы соответствующие значения, фильтровать содержимое http-трафика и подменять опубликованные "отпечатки" своими.
Line 17: Line 19:
На stunnel.org есть примеры. Посмотрим в документацию: man stunnel. Полезно также изучить примеры с stunnel.org.
Line 19: Line 21:
Два параметра: -d, чтобы он работал в качестве демона, -r --- к какому порту присоединяться, потом двоеточие, номер порта. Обратите внимание на то, что можно использовать как числовые номера, так и символьные. Есть организация IANA, которая среди прочего регистрирует номера портов (например 443 это hhtps и тд.), и они хранятся в файле /etc/services. Вот например мы не используем 80 порт, так как там может стоять обычный web-сервер, и не используем 8080, так как он здесь тоже занят, и поэтому возьмем 8088. Обратим внимание на следующие параметры:

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

Пусть PID-файл хранится в нашем домашнем каталоге ~. Подключаемся мы к машине webmail.cs.msu.su по порту https (он имеет номер 443, о чем можно узнать в /etc/services). В качестве же локального порта укажем 8088 (стандартный порт http --- 80 --- может быть занят обычным web-сервером, а 8080 в нашем случае используется alterator-httpd).
Line 23: Line 32:
$ netstat -ltnp | grep stunnel }}}

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

{{{
# netstat -ltnp | grep stunnel
Line 27: Line 41:
Как видно, stunnel успешно запустилась и принимает соединения.
Line 28: Line 43:
Теперь мы можем зайти на localhost:8088 и увидеть то же самое. Если мы теперь попробуем подключиться с помощью браузера к localhost:8088, мы увидим обычный "незащищенный" сайт:
Line 30: Line 46:
Зачем вообще такое нужно? Когда вы заходите на localhost, считается, что подсмотреть трафик очень сложно, а те, кто могут, имеют рута на машине и тогда уже всё равно. Если такого нету, то есть, подсоединение осуществляется по сети в защищенном режиме, и никто ничего не увидит.
Line 32: Line 47:
Есть скрипт, который генерирует сертификаты, у него есть разные опции, в том числе есть опция отвечающая за подписывание. И может быть можно будет запустить stunnel со стороны сервера, чтобы он преобразовывал 80-й порт в какой ещё, но уже защищенный. Зачем может пригодиться такая схема? В результате наших действий незащищенное подключение устанавливается только к локальной машине (localhost). Считается, что подсмотреть трафик в этом случае очень сложно. Те, у кого такая возможность есть, обычно обладают "полноценными" правами суперпользователя на данной машине, а значит, имеют практически неограниченные возможности обхода любой защиты. Если же этот вариант исключить, то остается "подсматривать" внутрь защищенного SSL подключения по сети, что в нормальном случае довольно бесполезно.
Line 34: Line 49:
На чём часть про stunnel заканчивается.
Line 42: Line 56:
|| 20 || 1 || 1 || 1 || || 1 || SergeyKorobkov, DmitryChistikov, MaximByshevskiKonopko || || || || 40 || 1 || 1 || 1 || || 1 || SergeyKorobkov, DmitryChistikov, MaximByshevskiKonopko || || ||

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

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

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

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

Проиллюстрируем первый способ использования Stunnel. Рассмотрим сайт https://webmail.cs.msu.su/ --- web-интерфейс почтового сервера факультета ВМК МГУ. При подключении к данному сайту браузер обратит наше внимание на то, что подключение защищено с помощью SSL, адресная строка при этом имеет желтый фон:

../https_site.png

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

../https_site_properties.png

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

Посмотрим в документацию: man stunnel. Полезно также изучить примеры с stunnel.org.

Обратим внимание на следующие параметры:

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

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

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

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

# netstat -ltnp | grep stunnel
tcp     0    0 0.0.0.0:8088     0.0.0.0:*         LISTEN       4667/stunnel

Как видно, stunnel успешно запустилась и принимает соединения.

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

../https_site_stunnel.png

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

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

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

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

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

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

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

Level

Maintainer

Start date

End date

40

1

1

1

1

SergeyKorobkov, DmitryChistikov, MaximByshevskiKonopko

CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

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