На днях столкнулся реальной проблемой, которая отняла у меня немало часов возни со своим Linux’ом – я отправился в отпуск с ноутбуком (конечно, отпуск это отрада, а не проблема). Вроде Wi-Fi интерфейс есть, Linux работает и подсоединяется с Интернетом везде. Но все коммуникации (почта, Web, ICQ, Yahoo Messenger) идут по тем каналам, которые я совсем не знаю – кто их прослушивает, как они фильтруются и т.п. Совсем не хотелось в какой-нибудь гостинице “случайно” потерять свои пароли, которые в случае FTP, ICQ или многих веб-сайтов (например, форумов, где я участвую, или блогов, где пишу) идут открытым текстом в TCP/IP трафике. Ведь в наше время любой администратор сети может поставить программу-сниффер для прослушивания локальной сети и автоматического сбора паролей. Вот и пришлось повозиться, решая данную задачу.
С почтой кое-как разобрался. Настроил почтовый сервер в компании на работу с SSL как при получении, так и при отправке. Но что делать с другим трафиком? Было два варианта: настроить VPN-сервер на сервере фирмы и ходить через этот канал (поверх канала, который предоставляет местный провайдер), или же построить шифрованный туннель посредством маленькой программы stunnel. Почему-то OpenVPN не получилось настроить даже после двух дней изучения – признаюсь, был занят отпускными хлопотами, не разобрался – поэтому я вспомнил про stunnel.
Stunnel (веб-сайт stunnel.org) это маленькая программа, которая сидит как на серверной, так и на клиентской стороне, чтобы соединить два порта (клиентский и серверный) шифрованным каналом. Ее часто используют, чтобы добавить “секурный” порт веб-серверу, который не поддерживает SSL, или то же самое – почтовому серверу, работающему только по POP3 и только на 110-м порте. Серверный скрипт “вешается” на порт 443 и передает (внутри сервера) все запросы на порт 80 – в случае веб-сервера. Весь трафик от клиента до сервера идет по надежному каналу, а внутренний трафик никто прослушать уже не сможет, не взломав сам сервер.
Что же надо сделать на стороне клиента? Поставив stunnel на клиентскую машину, можно запрашивать не 80-й порт сервера, а 80-й порт локальной машины, а уже с этого порта будет туннель на 443-й порт сервера. Конечно, тут пример неудачный получился, потому что современные браузеры и так умеют общаться с 443-ми портами веб-серверов. Но в моем случае надо было защитить еще и “аську”. По этой причине я решил, что все программы, работающие с Интернетом, будут использовать прокси, а общаться с прокси буду по защищенному каналу. Следовательно, была выбрана такая архитектура:
- на сервере прокси-сервер squid слушает запросы на порте 3128, как обычно. Прокси запрашивает пароль при первом входе
- на сервере stunnel слушает порт 3129 (взят с потолка), перенаправляя все запросы на 3128
- на клиенте stunnel слушает порт 3128 и соединяется с сервером на 3129 защищенным образом
- все программы настроены на работу с “прокси-сервером” по адресу 127.0.0.1: 3128.
Теперь все программы общаются с местным прокси “открытым текстом”. Этот текст затем шифруется и отправляется по туннелю на сервер и там обрабатывается. Результат запроса (страницы веба, сообщения от людей и т.п.) возвращаются по туннелю на мою машину. Теперь ни один человек не сможет это перехватить! Конечно теоретически 
, а практически, может быть, моя машина дырявая.
Но теперь работать стало значительно спокойнее. Думаю, что и дома буду продолжать использовать установленный туннель. Зачем ломать то, что работает, при том, что оно еще и надежнее, чем обычно.
Кому интересно, как я все настроил, то настройки были произведены следующие. Напомню, что работаю в основном с Redhat-серверами и Fedora на десктопе. На обоих концах я установил stunnel (up2date -i stunnel на сервере и yum install stunnel на десктопе). У меня версия 4, поэтому конфигурационные файлы приводятся для этой версии. Внимание! На сайте stunnel.org пока что устаревшая документация, формат команд от третьей версии…
Сервер: файл /etc/stunnel/stunnel.conf
[root@www root]# more /etc/stunnel/stunnel.conf
# Provide the full path to your certificate-key pair file
cert = /etc/stunnel/stunnel.pem
# lock the process into a chroot jail
chroot = /var/run/stunnel/
# and create the PID file in this jail
pid = /stunnel.pid
# change the UID and GID of the process for security reasons
setuid = nobody
setgid = nobody
# Configure our secured services
##debug = 7
##output = /var/log/stunnel.log
[ssquid]
accept = 3129
connect = 3128
Всего несколько строчек (не считая комментариев)!
Клиент: тоже /etc/stunnel/stunnel.conf
[tim@localhost ~]$ sudo more /etc/stunnel/stunnel.conf
Password:
cert = /etc/stunnel/stunnel.pem
# chroot = /var/tmp/stunnel
# PID is created inside chroot jail
# pid = /stunnel.pid
#setuid = stunnel
#setgid = stunnel
client = yes
##debug = 7
##output = /var/log/stunnel.log
[3129]
accept = 3128
connect = адрес_IP_сервера:3129
Тоже всего чуть-чуть! Разница только в флаге client=yes и адресе для параметра connect. Архитектура очень прозрачная.
Я также хотел бы помочь тем, кто устанавливает это впервые – я сам испытал это на себе – не сразу понятно, откуда взять нужный stunnel.pem – ключ для шифрования канала. Его можно сгенерировать из веб-интерфейса на stunnel.org, но это если совсем туго и у меня полученный ключ не работал – видимо, сайт генерит его для старой версии 3. Но затем я нашел простое решение для redhat-подобных дистрибутивов. Это, опять же, всего две команды:
cd /usr/share/ssl/certs
make /etc/stunnel/stunnel.pem
Надо только ответить на несколько вопросов скрипта make – отвечать можно произвольным образом, если этот сертификат больше нигде не будет использоваться. На моей локальной машине папки /usr/share/ssl/certs не нашлось (видимо, нужно установить openssl-devel), поэтому я поступил еще банальнее – скопировал на локальную машину файл stunnel.pem, полученный на сервере.
После всего этого надо просто добавить в автозапуск – в redhat-подобных дистрибутивах можно использовать файл /etc/rc.local – я в конец файла добавил строчку stunnel – и все!
После запуска команды stunnel на сервере и на клиенте (это только один раз нужно) туннель устанавливается и можно общаться без боязни прослушивания. Ура!
источник: http://www.prolinux.ru/linux-practice/stunnel-secure-communication/
ссылка на материал: http://thin.kiev.ua/categoryblog/726-stunnel.html
{jcomments on}
