LXF168:Удаленный доступ Shellinabox - История изменений

Olkol: /* Защищенный доступ через web-браузер */

2018-11-10T17:57:58Z

‎Защищенный доступ через web-браузер

Olkol: /* Погружаемся */

2018-11-10T17:49:42Z

‎Погружаемся

Olkol: Новая страница: «Категория: Учебники == Защищенный доступ через web-браузер == Крис Нотли покаже…»

2018-11-10T17:46:45Z

Новая страница: «Категория: Учебники == Защищенный доступ через web-браузер == Крис Нотли покаже…»

Новая страница

[[Категория: Учебники]]
== Защищенный доступ через web-браузер ==

Крис Нотли покажет, как употребить Shellinabox с обратным прокси Apache для обеспечения защищенного доступа к Linux-компьютеру только через браузер.

Удаленный доступ к оболочке домашнего сервера стал для меня нормой жизни, и без него мне было бы трудно обойтись. Нужно ли проверить возможность подключения к удаленному сайту, изменить скрипт мониторинга или просто перезапустить сервис – мне больше незачем мчаться для этого домой.

Полноценные VPN-решения с использованием IPSEC или PPTP дают гибкий доступ ко всей сети, но для их безопасной настройки придется потрудиться, а в корпоративных сетях такой трафик обычно запрещен брандмауэрами.

На другом конце шкалы – SSH-подключение напрямую к серверу через роутер или брандмауэр является и защищенным, и относительно простым, но SSH-доступ во многих сетях бывает невозможен. Самая частая причина проблем – стандартный порт SSH (TCP/22) запрещен брандмауэром (так нередко бывает в корпоративных сетях и в точках публичного доступа к Интернету). Иногда проблему можно решить, перенастроив SSH-сервер так, чтобы он слушал порт, связанный с web-сервисами (например, TCP/80 или TCP/443). Однако ничего не получится, если на том же хосте должен работать web-сервер. Это решение также встречает более серьезные препятствия в больших корпоративных сетях, где доступ к web-портам обычно осуществляется через прокси.

Еще одно потенциальное ограничение может возникнуть, если вы пользуетесь чужим компьютером для доступа. На заблокированных терминалах – например, на ограниченных в правах корпоративных компьютерах или киосках – может не быть SSH-клиента, и установить его нельзя. Программы для доступа к оболочке или к терминалу через web-браузер существуют довольно долго, но обычно используют Java со всеми проблемами совместимости, которые мы научились любить! С ростом возможностей современных браузеров (в частности, с развитием движков JavaScript в этих браузерах) стало возможным найти решение, не использующее плагины вроде Java.

===Shellinabox===

Shellinabox – web-эмулятор терминала на Ajax, совместимый с большинством современных web-браузеров, поддерживающих CSS и JavaScript. Серверная часть программы представляет собой выделенный web-сервер, который при подключении клиента по умолчанию запускает /bin/login, выводя приглашение для ввода логина/пароля, и после успешной аутентификации запускает оболочку клиента по умолчанию.

Shellinabox запускается как демон и по умолчанию слушает защищенные соединения на порту TCP/4200. Порт можно заменить на TCP/443, то есть порт, зарезервированный для защищенных HTTP-соединений, но это приводит к двум большим проблемам. Первая – в том, что во многих случаях вы можете захотеть запустить другие web-сервисы через защищенные соединения с того же компьютера. Вторая – встроенный web-сервер предоставляет мало возможностей для тонкого контроля доступа, поэтому каждый, кто подключится к серверу через web-браузер, увидит приглашение для входа в систему. Внешний вид Shellinabox легко изменить, и для этого не понадобится ничего, кроме CSS.

В отличие от некоторых альтернатив, Shellinabox предоставляет полноценный эмулятор терминала на JavaScript, а значит, в нем можно выполнять самые разнообразные действия, обычно выполняемые в терминале. Прекрасный пример этого – домашняя страница Shellinabox (http://code.google.com/p/shellinabox/).

===Web-прокси===

Web-прокси – это сервис, который сидит между web-клиентом и сервером и существует в двух вариантах. Первый – прямой прокси, и его клиенты обычно должны знать о нем (как знают большинство браузеров). При возникновении запроса (например, при вводе адреса в браузер, в котором настроен прокси), клиент отправляет запрос прокси, который, в свою очередь, запрашивает содержимое непосредственно у запрашиваемого web-сервера. Затем прокси возвращает это содержимое клиенту. Прямой прокси также можно настроить в прозрачном режиме, тогда клиентам не нужно знать о прокси. В прямых прокси обычно есть некая форма для управления содержимым, на которой можно заблокировать доступ к нежелательным сайтом. Они также обычно кэшируют статическое содержимое, например, изображения, поэтому у многих провайдеров настроены прозрачные прямые прокси для экономии канала.

Второй вариант – обратный прокси, и на нашем уроке мы им и воспользуемся. Основное различие между обратным и прямым прокси в том, что обратный прикрывает определенные сайты или содержимое на стороне сервера, а прямой прокси обычно возвращает любое запрошенное содержимое. Web-клиентам не нужно знать, что сайт обслуживается обратным прокси, адрес будет указывать прямо на прокси, а клиент просто увидит ответ на свой запрос. С помощью обратного прокси можно применить к набору серверов постоянную конфигурацию безопасности вместо того, чтобы выполнять одни и те же настройки на каждом из них.

===Apache===

Существует немало обратных прокси для Linux, но мы возьмем Apache. В модуле прокси Apache можно настроить пути (например, http://webserver/path1), ссылающиеся на другой сервер, а не на HTML-файлы на локальном диске. Это не обязательно физически отдельный сервер, это может быть и другой демон web-сервера на том же компьютере. Преимущество Apache здесь в том, что в нем легко управлять доступом к сервисам. Например, можно включить какую-либо форму аутентификации и/или явно разрешить или запретить подключение с определенных IP-адресов и т. д.

Некоторые web-приложения нужно немного доработать, прежде чем помещать их за обратный прокси. В частности, изменить абсолютные ссылки на относительные (например, <link rel=“stylesheet” type=“text/css” href= “/css/default.css”> вместо <link rel=“stylesheet” type=“text/css” href= “../css/default.css”> – заметьте две точки во втором примере). Чтобы обойти проблему, может потребоваться способность Apache переписывать содержимое. К счастью для нас, Shellinabox легко интегрируется с обычным прокси, и менять ничего не придется.
{{Врезка|right|Заголовок= Скорая помощь|Ширина=10%|Содержание=
Когда у вас будет рабочий обратный прокси, примените его для безопасного удаленного web-доступа к такому оборудованию, как цифровые ресиверы, серверы NAS и т. д. }}
Еще одно большое преимущество Apache как обратного прокси в том, что можно продолжать обрабатывать другие web-запросы с его помощью. В моем случае Apache обслуживает Shellinabox вместе с MythWeb, phpMyAdmin и еще несколькими домодельными web-приложениями.

Соединив возможности Shellinabox с обратным прокси Apache, можно получить еще один метод удаленного доступа, совместимый почти со всеми операционными системами и конфигурациями брандмауэра, а также довольно эффектный при демонстрации другим пользователям! И Shellinabox, и Apache есть в стандартных репозиториях многих современных дистрибутивов Linux, и заставить обоих работать не так уж сложно. На нашем уроке мы установим Shellinabox и настроим его для работы с Apache на чистой установке Ubuntu 12.10 Server. Мы также рассмотрим два предыдущих релиза Ubuntu LTS (12.04 и 10.04). В других дистрибутивов местоположение файла настройки может быть другим. Однако большая часть этого руководства все равно подойдет.

===Погружаемся===

Первый этап – установка чистой системы Ubuntu Server (12.10). Если вы хотите сделать это в VirtualBox, можно скачать готовый образ у отличных ребят из VirtualBoxImages (http://bit.ly/T0CDjH). При установке Ubuntu Server с нуля, единственное рекомендуемое изменение в конфигурации – включить сервер OpenSSH на этапе выбора программ [Software Selection] во время установки.

В случае готового образа с VirtualBoxImages надо учесть несколько моментов. Виртуальная машина попытается включить интерфейс WLAN1, поэтому обязательно задайте правильный интерфейс в настройках. По умолчанию настроено получение IP-адреса по DHCP – можно либо изменить его на статический адрес, либо записать назначенный адрес (и далее до конца урока заменять SERVER_IP на этот адрес).
[[Файл: LXF168.tut_shellbox.s_opt1.jpeg| |thumb|400px|> Типичный обратный прокси в действии.]]
В образе VirtualBox, на который мы ссылались выше, по умолчанию установлена итальянская раскладка клавиатуры; если вам нужна другая, скомандуйте

sudo dpkg-reconfigure keyboard-configuration

Вам предложат изменить несколько параметров, включая страну – задайте их соответствующим образом. Если вы новичок в работе с сервисами, открытыми для доступа извне, то невероятно полезной станет привычка регулярно обновлять систему. Сервисы вроде Apache обновляются регулярно, и это позволит вам минимизировать уязвимость компьютера для внешних воздействий.

Сервер можно обновить с командной строки, запустив следующие команды:

sudo apt-get update

sudo apt-get -y dist-upgrade

sudo shutdown -r now

После перезагрузки сервера установите Apache, командой

sudo apt-get install -y apache2

Затем нужно установить Shellinabox, и способ установки зависит от вашей версии Ubuntu. В репозиториях Ubuntu 12.10 уже есть Shellinabox, и ее можно установить командой

sudo apt-get install -y shellinabox

В репозиториях Ubuntu 12.04 и ранее ее нет, и ее нужно загрузить и установить. Версия файла зависит от того, 32- или 64-разрядной версией Ubuntu вы пользуетесь:

32-битная:

wget http://shellinabox.googlecode.com/files/shellinabox_2.10-1_i386.deb

sudo dpkg -i shellinabox_2.10-1_i386.deb

64-битная:

wget http://shellinabox.googlecode.com/files/shellinabox_2.10-1_amd64.deb

sudo dpkg -i shellinabox_2.10-1_amd64.deb

Теперь можно проверить базовую функциональность Shellinabox, открыв браузер и набрав https://SERVER_IP:4200. Браузер пожалуется на сертификат SSL, который является самоподписанным. Нажав «Продолжить», вы увидите интерфейс Shellinabox по умолчанию со строкой входа в систему. Осмотрите интерфейс. Попробуйте все команды и меню, которыми обычно пользуетесь, перед тем, как мы настроим Shellinabox для работы с Apache.
{{Врезка|left|Заголовок=А нужен ли брандмауэр? |Ширина=40%|Содержание=В Ubuntu брандмауэр по умолчанию не включен ни в настольной, ни в серверной версии. Для большинства домашних компьютеров это редко является проблемой, так как широкополосные роутеры обычно по умолчанию не перенаправляют входящие соединения к внутренним компьютерам.

Самый простой и безопасный способ развернуть сочетание Shellinabox/Apache – перенаправлять на сервер через роутер только защищенные web-запросы (TCP/443). Некоторые широкополосные роутеры способны перенаправить все входящие соединения на указанный внутренний компьютер (это часто называется «режим (или хост) демилитаризованной зоны, DMZ»). Это удобно, если на сервере есть набор разных сервисов, однако в этом случае я настоятельно рекомендовал бы запустить брандмауэр.

На сервере Ubuntu проще всего воспользоваться UFW (Uncomplicated Firewall – несложный брандмауэр). Следующий скрипт активирует UFW и разрешает соединения по SSH и защищенные web-соединения отовсюду:

sudo ufw enable

sudo ufw allow ssh

sudo ufw allow https
}}
Чтобы пользоваться Shellinabox через Apache, в настройки по умолчанию нужно внести несколько изменений. Откройте файл /etc/default/shellinabox в любимом текстовом редакторе и выполните следующие изменения:

До:

SHELLINABOX_ARGS=”--no-beep”

После:

SHELLINABOX_ARGS=”--no-beep --localhost-only --disablessl”

Первый аргумент (--localhost-only) велит Shellinabox слушать соединения только с собственного сетевого адаптера. Эта важная мера предосторожности гарантирует, что подключаться к Shellinabox смогут только процессы, запущенные локально на сервере, и не позволит подключаться напрямую к сервису из-за неправильно настроенного брандмауэра или некорректного правила NAT.

Второй аргумент (--disable-ssl) разрешает Shellinabox принимать только незашифрованные подключения. Сначала это может показаться непонятным, так как мы строим защищенную систему. Однако подключения к демону Shellinabox всегда будут выполняться только Apache через сетевую карту сервера. Соединение должно быть незащищенным, потому что Shellinabox использует самоподписанный сертификат, которому Apache доверять не будет.

Следующий шаг – перезагрузить демон Shellinabox, чтобы он перечитал конфигурацию. Сделать это можно командой

sudo service shellinabox restart

Shellinabox настроен – можно перейти к Apache, и сначала настроим его на прослушивание защищенных соединений.

sudo a2ensite default-ssl

sudo a2enmod ssl

sudo service apache2 restart

Если Apache не используется для предоставления других web-сервисов, можно настроить его так, чтобы он принимал только защищенные соединения.

sudo a2dissite default

Также откройте файл /etc/apache2/ports.conf в своем любимом редакторе и измените следующее:

До:

NameVirtualHost *:80

Listen 80

После:

#NameVirtualHost *:80

#Listen 80

Следующий шаг – включить обратный прокси в Apache, чтобы он смог работать с Shellinabox. Это сделает команда

sudo a2enmod proxy proxy_http

sudo service apache2 restart

Теперь нужно разрешить доступ к Shellinabox в файле настройки Apache. Настройки можно поместить в конфигурации виртуального хоста или глобально. Первый подход удобен в том случае, если на одном и том же компьютере будут находиться и защищенные, и незащищенные web-сервисы, но обратный прокси будет работать только с защищенными соединениями. В этом случае нужно изменить файл сайта SSL по умолчанию, в Ubuntu это /etc/apache2/sites-enabled/default-ssl. Здесь мы уже отключили незашифрованный доступ к Apache, поэтому настройки безопасно поместить в глобальный раздел.

Откройте файл /etc/apache2/mods-enabled/proxy.conf в любимом текстовом редакторе и замените его содержимое на следующее:

<IfModule mod_proxy.c>

ProxyRequests Off

<Proxy *>

AuthType Basic

AuthName “The computer says no!”

AuthUserFile /etc/apache2/htpasswd.default

Require valid-user

Order allow,deny

Satisfy any

</Proxy>

ProxyPass /siab http://127.0.0.1:4200/

</IfModule>

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

Следующий раздел определяет то, как предоставляется доступ для запросов прокси, и в данном случае мы пользуемся базовой аутентификацией HTTP. Директива AuthName задает сообщение, которые увидят пользователи, подключившиеся к серверу, и здесь по-настоящему важно не показывать, что находится за приглашением о входе в систему. Сообщение «Вход в оболочку!! [Login for shell access!!]» – исключительно неудачный выбор!

Директива AuthUserFile ссылается на внешний файл с именами и паролями пользователей, имеющих доступ к файлу. Этот файл мы создадим на следующем этапе. Остальные директивы говорят Apache, что для доступа к сервису пользователь должен успешно аутентифицироваться.
{{Врезка|right|Заголовок=Скорая помощь |Ширина=10%|Содержание=С самоподписанным сертификатом вы привыкнете игнорировать ошибки браузера и с меньшей вероятностью обнаружите настоящую атаку. Чтобы этого избежать, бесплатно загрузите сертификат, которому доверяют большинство браузеров, с сайта startssl.com.}}
Теперь надо создать файл с паролем, заданный в предыдущем файле настройки, с помощью утилиты htpasswd, командой

sudo htpasswd -c /etc/apache2/htpasswd.default siab

Утилита htpasswd создаст файл паролей и попросит ввести и подтвердить пароль для нового пользователя – в примере выше это пользователь siab. Имя этого пользователя должно обязательно отличаться от имени пользователя, используемого для входа на сервер (через консоль, по SSH и т. д.). Пароль тоже должен быть довольно надежным, так как с его помощью можно легко, но эффективно скрыть факт наличия доступа к оболочке.

Теперь мы готовы проверить подключение к серверу, но нужно в последний раз перезапустить Apache, чтобы он загрузил настройки обратного прокси:

sudo service apache2

restart

Теперь можно запустить браузер и открыть в нем адрес https://SERVER_IP/siab. Сайт SSL по умолчанию использует самоподписанный сертификат, поэтому появится предупреждение, но его можно спокойно игнорировать. Затем вам предложат ввести имя пользователя и пароль, созданные утилитой htpasswd. Должен появиться экран входа в систему Shellinabox, из которого можно войти в систему с обычными именем пользователя/паролем оболочки.

Теперь все работает, и можно спокойно включить перенаправление портов на роутере и удаленно подключиться к оболочке! |

← Предыдущая		Версия 17:49, 10 ноября 2018
Строка 190:		Строка 190:
	Теперь можно запустить браузер и открыть в нем адрес https://SERVER_IP/siab. Сайт SSL по умолчанию использует самоподписанный сертификат, поэтому появится предупреждение, но его можно спокойно игнорировать. Затем вам предложат ввести имя пользователя и пароль, созданные утилитой htpasswd. Должен появиться экран входа в систему Shellinabox, из которого можно войти в систему с обычными именем пользователя/паролем оболочки.		Теперь можно запустить браузер и открыть в нем адрес https://SERVER_IP/siab. Сайт SSL по умолчанию использует самоподписанный сертификат, поэтому появится предупреждение, но его можно спокойно игнорировать. Затем вам предложат ввести имя пользователя и пароль, созданные утилитой htpasswd. Должен появиться экран входа в систему Shellinabox, из которого можно войти в систему с обычными именем пользователя/паролем оболочки.

−	Теперь все работает, и можно спокойно включить перенаправление портов на роутере и удаленно подключиться к оболочке! \|	+	Теперь все работает, и можно спокойно включить перенаправление портов на роутере и удаленно подключиться к оболочке!
		+
		+	{{Врезка\|left\|Заголовок= Постоянные сеансы оболочки\|Ширина=98%\|Содержание=Выполнять команды по беспроводной сети или широковещательному соединению, когда связь ведет себя своенравно, может быть сложно. Обрыв связи во время обновления программы или редактирования файла может оставить вашу систему в не лучшем виде.
		+
		+	Один очень простой способ этого избежать – привыкнуть пользоваться программой Screen для постоянных сеансов оболочки. Screen – полноэкранный оконный менеджер, позволяющий создавать виртуальные сеансы, которые могут сохраняться в разных подключениях. В Ubuntu Server он установлен по умолчанию, в других версиях Ubuntu, а также в большинстве других дистрибутивов Linux его легко установить из репозиториев.
		+
		+	Запустить новый сеанс Screen очень просто – наберите screen, и, нажав пробел, чтобы убрать информационное окно, вы попадете в свою оболочку по умолчанию.
		+
		+	Команды в Screen отправляются по нажатию Ctrl + A, а если затем нажать ?, вы увидите список всех команд. Нам наиболее интересна команда отключения (Ctrl + A, d), которая отключит вас от сеанса Screen, оставив его работать в фоне. Повторно подключиться к этому сеансу можно, набрав screen -r. Если связь оборвется и Screen скажет, что вы уже подключены к сеансу, просто наберите screen -d –r, и подключитесь к сеансу принудительно.
		+
		+	Привычка пользоваться Screen при удаленном подключении позволит решать все задачи в оболочке, не опасаясь обрыва связи, и вы можете начать пользоваться ею даже в локальной сети! }} \|

@@ Строка 2: / Строка 2: @@
 == Защищенный доступ через web-браузер ==
-Крис Нотли покажет, как употребить Shellinabox с обратным прокси Apache для обеспечения защищенного доступа к Linux-компьютеру только через браузер.
+''Крис Нотли покажет, как употребить Shellinabox с обратным прокси Apache для обеспечения защищенного доступа к Linux-компьютеру только через браузер.''
+[[Файл:LXF168.tut_shellboxExpert.png |left |100px |thumb|'''Наш эксперт''' Крис Нотли пользуется Linux и работает с ним более 12 лет, но реально подсел на него, открыв прелести Asterisk и MythTV.]]
 Удаленный доступ к оболочке домашнего сервера стал для меня нормой жизни, и без него мне было бы трудно обойтись. Нужно ли проверить возможность подключения к удаленному сайту, изменить скрипт мониторинга или просто перезапустить сервис – мне больше незачем мчаться для этого домой.

LXF168:Уда­лен­ный доступ Shellinabox - История изменений

Olkol: /* За­щи­щен­ный дос­туп че­рез web-брау­зер */

Olkol: /* По­гру­жа­ем­ся */

Olkol: Новая страница: «Категория: Учебники == За­щи­щен­ный дос­туп че­рез web-брау­зер == Крис Нот­ли по­ка­же…»

LXF168:Удаленный доступ Shellinabox - История изменений

Olkol: /* Защищенный доступ через web-браузер */

Olkol: /* Погружаемся */

Olkol: Новая страница: «Категория: Учебники == Защищенный доступ через web-браузер == Крис Нотли покаже…»