8353
Комментарий:
|
9532
|
Удаления помечены так. | Добавления помечены так. |
Строка 3: | Строка 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/]]. |
Строка 5: | Строка 5: |
В первом случае stunnel запускается с клиентской машины и организует доступ к серверу, принимающему защищенные с помощью SSL подключения. Она прокидывает к серверу туннель и открывает на клиентской машине специальный порт, к которому можно подключаться без SSL. Подключения будут автоматически защищаться SSL и пробрасываться на сервер (работу с SSL при такой схеме stunnel берет на себя). | Первый способ использования stunnel --- это запуск с клиентской машины для организации доступа к серверу, который принимает защищенные с помощью SSL подключения. Stunnel прокидывает к серверу туннель и открывает на клиентской машине специальный порт, к которому можно подключаться без SSL. Подключения будут автоматически защищаться SSL и пробрасываться на сервер. Вся работа с SSL при такой схеме осуществляется самой программой stunnel. |
Строка 7: | Строка 7: |
Второй способ использования stunnel состоит в организации защиты для не умеющего SSL сервера (pppd, imapd). Схема работы stunnel в таком случае напоминает использование xinetd, только в данном случае соединения принимаются программой stunnel (она берет на себя создание SSL-прослойки), которая выступает в роли фильтра. | Второй способ использования stunnel состоит в организации защиты для не умеющего использовать SSL сервера (примерами могут служить pppd и imapd). Схема работы stunnel в таком случае напоминает использование xinetd: она создает SSL-прослойку и принимает входящие (защищенные) соединения, выступая, таким образом, в роли фильтра. |
Строка 9: | Строка 9: |
Проиллюстрируем первый способ использования Stunnel. Рассмотрим сайт https://webmail.cs.msu.su/ --- web-интерфейс почтового сервера факультета ВМК МГУ. При подключении к данному сайту браузер обратит наше внимание на то, что подключение защищено с помощью SSL, адресная строка при этом имеет желтый фон: | Проиллюстрируем первый способ использования Stunnel. Посмотрим на сайт [[https://webmail.cs.msu.su/]] --- web-интерфейс почтового сервера факультета ВМК МГУ. При подключении браузер обратит наше внимание на то, что соединение защищено с помощью SSL. Адресная строка при этом получит желтый фон: |
Строка 17: | Строка 17: |
Это совпадение и должно убеждать нас в том, что сайт "подлинный", то есть с нами "разговаривает" именно webmail.cs.msu.su. Конечно, злоумышленник может встать на пути между нами и доверенным сайтом и выполнить более сложную операцию: подменить не только сертификат, но и поменять значение "отпечатков пальцев" на странице. Вероятность подобного, однако, значительно меньше: необходимо найти место на сайте, где опубликованы соответствующие значения, фильтровать содержимое http-трафика и подменять опубликованные "отпечатки" своими. | Это совпадение и должно убеждать нас в том, что сайт "подлинный", иными словами --- что "разговаривает" с нами именно webmail.cs.msu.su. Конечно, злоумышленник может встать на пути между нами и доверенным сайтом и выполнить более сложную операцию: подменить не только сертификат, но и значения "отпечатков пальцев" на странице. Вероятность подобного, однако, значительно меньше: необходимо заранее найти место на сайте, где опубликованы соответствующие значения, и в дальнейшем при перехвате соединения фильтровать содержимое http-трафика, подменяя опубликованные "отпечатки" своими. |
Строка 19: | Строка 19: |
Посмотрим в документацию: man stunnel. Полезно также изучить примеры с stunnel.org. | Попробуем использовать stunnel в режиме клиента. Посмотрим для этого в документацию и обратим внимание на следующие параметры: |
Строка 21: | Строка 21: |
Обратим внимание на следующие параметры: * -P --- в каком каталоге хранить PID-файл; * -c --- работать в режиме клиента (первый из описанных нами вариантов); * -d --- работать в режиме демона и принимать соединения на указанный порт; |
* -P --- каталог для хранения PID-файла; * -c --- работа в режиме клиента (первый из описанных нами способов использования); * -d --- работа в режиме демона и прием соединений на указанный порт; |
Строка 28: | Строка 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. |
Строка 34: | Строка 32: |
Поскольку мы указали программе stunnel работать в режиме демона, то мы снова увидим приглашение командной строки. Проверим, принимает ли теперь stunnel соединения. Перейдем в режим суперпользователя и воспользуемся утилитой netstat (ключ -l предписывает выводить лишь "слушающие" listening сокеты, -t --- только TCP-сокеты, -n указывает не использовать символьные имена портов и адресов, -p заставляет вывести PID и имя слушающей программы): | Поскольку мы указали программе stunnel работать в режиме демона, то мы снова увидим приглашение командной строки. Проверим, принимает ли теперь stunnel соединения. Воспользуемся для этого утилитой netstat. Нам понадобится список "слушающих" (ключ -l, listening) TCP-сокетов (ключ -t), причем удобнее использовать числовую форму (ключ -n, numeric) обозначений портов и Интернет-адресов. Главным для нас будет ключ -p, заставляющий netstat выводить PID и имя "слушающих" программ: |
Строка 37: | Строка 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.) |
Строка 41: | Строка 41: |
Как видно, stunnel успешно запустилась и принимает соединения. | Программа grep отфильтровала стандартный вывод netstat, оставив в нем лишь строку, содержащую слово stunnel (первые две строки были выведены в стандартный поток ошибок и поэтому не были отброшены). Как видно, stunnel успешно запустилась и принимает соединения на порту 8088 локальной машины. |
Строка 43: | Строка 43: |
Если мы теперь попробуем подключиться с помощью браузера к localhost:8088, мы увидим обычный "незащищенный" сайт: | Если мы теперь попробуем выполнить с помощью браузера подключение по адресу localhost:8088, то увидим обычный, "незащищенный" на первый взгляд сайт: |
Строка 47: | Строка 47: |
Зачем может пригодиться такая схема? В результате наших действий незащищенное подключение устанавливается только к локальной машине (localhost). Считается, что подсмотреть трафик в этом случае очень сложно. Те, у кого такая возможность есть, обычно обладают "полноценными" правами суперпользователя на данной машине, а значит, имеют практически неограниченные возможности обхода любой защиты. Если же этот вариант исключить, то остается "подсматривать" внутрь защищенного SSL подключения по сети, что в нормальном случае довольно бесполезно. |
Зачем может пригодиться такая схема? В результате наших действий незащищенное подключение устанавливается только к локальной машине (localhost). Считается, что подсмотреть трафик в этом случае очень сложно. Те, у кого такая возможность есть, обычно обладают "полноценными" правами суперпользователя на данной машине, а значит, имеют практически неограниченные возможности обхода любой защиты. Если же этот вариант исключить, то останется лишь "подсматривать" внутрь защищенного SSL подключения по сети, что в большинстве случаев совершенно бесполезно. |
Строка 56: | Строка 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. Адресная строка при этом получит желтый фон:
Указанные на сайте "отпечатки пальцев" --- это значения двух различных хэш-функций от публичного ключа сервера. Если просмотреть свойства сайта, то среди информации об используемом сертификате мы увидим такие же отпечатки:
Это совпадение и должно убеждать нас в том, что сайт "подлинный", иными словами --- что "разговаривает" с нами именно 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, то увидим обычный, "незащищенный" на первый взгляд сайт:
Зачем может пригодиться такая схема? В результате наших действий незащищенное подключение устанавливается только к локальной машине (localhost). Считается, что подсмотреть трафик в этом случае очень сложно. Те, у кого такая возможность есть, обычно обладают "полноценными" правами суперпользователя на данной машине, а значит, имеют практически неограниченные возможности обхода любой защиты. Если же этот вариант исключить, то останется лишь "подсматривать" внутрь защищенного SSL подключения по сети, что в большинстве случаев совершенно бесполезно.
Сведения о ресурсах
Готовность (%) |
Продолжительность (ак. ч.) |
Подготовка (календ. ч.) |
Полный текст (раб. д.) |
Предварительные знания |
Level |
Maintainer |
Start date |
End date |
41 |
1 |
1 |
1 |
|
1 |
|
|