Differences between revisions 13 and 14
Revision 13 as of 2008-08-04 09:46:54
Size: 8353
Comment:
Revision 14 as of 2008-08-04 11:23:41
Size: 9532
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Установим пакет stunnel командой `apt-get install stunnel` (для этого, возможно, придется подключить дополнительные репозитории: он не входит в состав ALT Linux Lite, но есть в школьном бранче) и рассмотрим соответствующую программу "поближе". Stunnel может служить как клиентом, так и сервером для организации защищенного с помощью SSL туннеля. Установим пакет 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 подключения. Она прокидывает к серверу туннель и открывает на клиентской машине специальный порт, к которому можно подключаться без SSL. Подключения будут автоматически защищаться SSL и пробрасываться на сервер (работу с SSL при такой схеме stunnel берет на себя). Первый способ использования stunnel --- это запуск с клиентской машины для организации доступа к серверу, который принимает защищенные с помощью SSL подключения. Stunnel прокидывает к серверу туннель и открывает на клиентской машине специальный порт, к которому можно подключаться без SSL. Подключения будут автоматически защищаться SSL и пробрасываться на сервер. Вся работа с SSL при такой схеме осуществляется самой программой stunnel.
Line 7: Line 7:
Второй способ использования stunnel состоит в организации защиты для не умеющего SSL сервера (pppd, imapd). Схема работы stunnel в таком случае напоминает использование xinetd, только в данном случае соединения принимаются программой stunnel (она берет на себя создание SSL-прослойки), которая выступает в роли фильтра. Второй способ использования stunnel состоит в организации защиты для не умеющего использовать SSL сервера (примерами могут служить pppd и imapd). Схема работы stunnel в таком случае напоминает использование xinetd: она создает SSL-прослойку и принимает входящие (защищенные) соединения, выступая, таким образом, в роли фильтра.
Line 9: Line 9:
Проиллюстрируем первый способ использования Stunnel. Рассмотрим сайт https://webmail.cs.msu.su/ --- web-интерфейс почтового сервера факультета ВМК МГУ. При подключении к данному сайту браузер обратит наше внимание на то, что подключение защищено с помощью SSL, адресная строка при этом имеет желтый фон: Проиллюстрируем первый способ использования Stunnel. Посмотрим на сайт [[https://webmail.cs.msu.su/]] --- web-интерфейс почтового сервера факультета ВМК МГУ. При подключении браузер обратит наше внимание на то, что соединение защищено с помощью SSL. Адресная строка при этом получит желтый фон:
Line 17: Line 17:
Это совпадение и должно убеждать нас в том, что сайт "подлинный", то есть с нами "разговаривает" именно webmail.cs.msu.su. Конечно, злоумышленник может встать на пути между нами и доверенным сайтом и выполнить более сложную операцию: подменить не только сертификат, но и поменять значение "отпечатков пальцев" на странице. Вероятность подобного, однако, значительно меньше: необходимо найти место на сайте, где опубликованы соответствующие значения, фильтровать содержимое http-трафика и подменять опубликованные "отпечатки" своими. Это совпадение и должно убеждать нас в том, что сайт "подлинный", иными словами --- что "разговаривает" с нами именно webmail.cs.msu.su. Конечно, злоумышленник может встать на пути между нами и доверенным сайтом и выполнить более сложную операцию: подменить не только сертификат, но и значения "отпечатков пальцев" на странице. Вероятность подобного, однако, значительно меньше: необходимо заранее найти место на сайте, где опубликованы соответствующие значения, и в дальнейшем при перехвате соединения фильтровать содержимое http-трафика, подменяя опубликованные "отпечатки" своими.
Line 19: Line 19:
Посмотрим в документацию: man stunnel. Полезно также изучить примеры с stunnel.org. Попробуем использовать stunnel в режиме клиента. Посмотрим для этого в документацию и обратим внимание на следующие параметры:
Line 21: Line 21:
Обратим внимание на следующие параметры:

* -P --- в каком каталоге хранить PID-файл;
 * -c --- работать в режиме клиента (первый из описанных нами вариантов);
 * -d --- работать в режиме демона и принимать соединения на указанный порт;
 * -P --- каталог для хранения PID-файла;
 * -c --- работа в режиме клиента (первый из описанных нами способов использования);
 * -d --- работа в режиме демона и прием соединений на указанный порт;
Line 28: Line 26:
Пусть PID-файл хранится в нашем домашнем каталоге ~. Подключаемся мы к машине webmail.cs.msu.su по порту https (он имеет номер 443, о чем можно узнать в /etc/services). В качестве же локального порта укажем 8088 (стандартный порт http --- 80 --- может быть занят обычным web-сервером, а 8080 в нашем случае используется alterator-httpd). Пусть PID-файл хранится в нашем домашнем каталоге ~. Подключаться мы будем к машине webmail.cs.msu.su по порту https --- он имеет номер 443, что подтверждается содержимым файла /etc/services. В качестве же локального порта укажем 8088: стандартный порт http (80) может быть занят обычным web-сервером, а порт 8080 в нашем случае используется web-интерфейсом конфигуратора Alterator.
Line 34: Line 32:
Поскольку мы указали программе stunnel работать в режиме демона, то мы снова увидим приглашение командной строки. Проверим, принимает ли теперь stunnel соединения. Перейдем в режим суперпользователя и воспользуемся утилитой netstat (ключ -l предписывает выводить лишь "слушающие" listening сокеты, -t --- только TCP-сокеты, -n указывает не использовать символьные имена портов и адресов, -p заставляет вывести PID и имя слушающей программы): Поскольку мы указали программе stunnel работать в режиме демона, то мы снова увидим приглашение командной строки. Проверим, принимает ли теперь stunnel соединения. Воспользуемся для этого утилитой netstat. Нам понадобится список "слушающих" (ключ -l, listening) TCP-сокетов (ключ -t), причем удобнее использовать числовую форму (ключ -n, numeric) обозначений портов и Интернет-адресов. Главным для нас будет ключ -p, заставляющий netstat выводить PID и имя "слушающих" программ:
Line 37: Line 35:
# netstat -ltnp | grep stunnel $ 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.)
Line 41: Line 41:
Как видно, stunnel успешно запустилась и принимает соединения. Программа grep отфильтровала стандартный вывод netstat, оставив в нем лишь строку, содержащую слово stunnel (первые две строки были выведены в стандартный поток ошибок и поэтому не были отброшены). Как видно, stunnel успешно запустилась и принимает соединения на порту 8088 локальной машины.
Line 43: Line 43:
Если мы теперь попробуем подключиться с помощью браузера к localhost:8088, мы увидим обычный "незащищенный" сайт: Если мы теперь попробуем выполнить с помощью браузера подключение по адресу localhost:8088, то увидим обычный, "незащищенный" на первый взгляд сайт:
Line 47: Line 47:
Зачем может пригодиться такая схема? В результате наших действий незащищенное подключение устанавливается только к локальной машине (localhost). Считается, что подсмотреть трафик в этом случае очень сложно. Те, у кого такая возможность есть, обычно обладают "полноценными" правами суперпользователя на данной машине, а значит, имеют практически неограниченные возможности обхода любой защиты. Если же этот вариант исключить, то остается "подсматривать" внутрь защищенного SSL подключения по сети, что в нормальном случае довольно бесполезно.
Зачем может пригодиться такая схема? В результате наших действий незащищенное подключение устанавливается только к локальной машине (localhost). Считается, что подсмотреть трафик в этом случае очень сложно. Те, у кого такая возможность есть, обычно обладают "полноценными" правами суперпользователя на данной машине, а значит, имеют практически неограниченные возможности обхода любой защиты. Если же этот вариант исключить, то останется лишь "подсматривать" внутрь защищенного SSL подключения по сети, что в большинстве случаев совершенно бесполезно.
Line 56: Line 55:
|| 40 || 1 || 1 || 1 || || 1 || SergeyKorobkov, DmitryChistikov, MaximByshevskiKonopko || || || || 41 || 1 || 1 || 1 || || 1 || SergeyKorobkov, DmitryChistikov, MaximByshevskiKonopko || || ||

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

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

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

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

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

../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

41

1

1

1

1

SergeyKorobkov, DmitryChistikov, MaximByshevskiKonopko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

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