Получение удаленного доступа к сервер

Часто в работе системного администратора могут возникать ситуации, при которых невозможен физически доступ к серверу (как пример, подключение через консоль), в таких случаях приходит на выручку удаленное подключение к серверу. Об этом мы поговорим далее.

Протоколы удаленного управления

Для подключения к удаленному хосту используются специализированные протоколы удаленного управления. Эти протоколы, реализующие модель «терминал-сервер», позволяют работать с ресурсами сервера так же, как и с локальными ресурсами: выполнять команды, работать с файловой системой, запускать приложения и т.п. С распространением персональных ЭВМ терминальный доступ стал использоваться в основном для решения задач удаленного администрирования.

Среди таких протоколов можно выделить:

  1. Telnet;

  2. rlogin;

  3. ssh (secure shell);

  4. RDP (remote desktop protocol);

  5. Веб-технологии удаленного управления;

Telnet

Служба удаленного управления telnet (Teletype Network) — одна из самых старых сетевых технологий Internet (первая спецификация — RFC 158 от 19.05.1971 г.). Текущая спецификация telnet — RFC 854/STD 8 – Telnet Protocol Specification. По умолчанию сервер telnet принимает входящие подключения на 23-ий порт TCP.

Протокол telnet изначально разрабатывался для использования в гетерогенных сетях. В его основе — концепция сетевого виртуального терминала (Network Virtual Terminal, NVT) — механизма абстрагирования от специфики ввода/вывода различных аппаратных и программных платформ. Сетевой виртуальный терминал NVT предлагает использование унифицированного набора символов, который используется для преобразования кодов клиента и сервера.

Хотя в сессии telnet выделяют клиентскую и серверную сторону, протокол является симметричным и обе стороны взаимодействуют через NVT, обмениваясь данными двух типов:

  • Прикладными данными (т.е. данными, которые идут от пользователя к серверному приложению и обратно);

  • Опциями протокола telnet, служащими для уяснения возможностей и предпочтений сторон.

Прикладные данные проходят через протокол без изменений т.е. на выходе второго виртуального терминала мы видим именно то, что было введено на вход первого. С точки зрения протокола эти данные – просто последовательность байтов (октетов), по умолчанию принадлежащих набору ASCII. Если же установлена опция Binary — то последовательность любых данных в двоичном представлении.

Все значения октетов прикладных данных кроме \377 (десятичное 255) передаются по транспорту как есть. Октет \377 передаётся последовательностью \377\377 из двух октетов. Это связано с тем, что октет \377 используется для кодирования опций протокола.

Telnet поддерживает четыре режима передачи:

  • Полудуплексный режим. NVT по умолчанию это полудуплексное устройство, которое требует исполнения специальной команды (GO AHEAD, GA) от сервера, перед тем как будет принят ввод от пользователя. Ввод пользователя отображается локальным эхом от NVT клавиатуры на NVT принтер, таким образом, от клиента к серверу посылаются только полные строки.

  • Посимвольный. Каждый вводимый символ отправляется серверу отдельно от других. Сервер отражает эхом (опция ECHO — RFC 857) большинство символов и эти символы отражаются на экране клиента.

  • Блочный. Отправка данных производится по принципу “строка за один раз”.

  • Линейный режим (linemode). В данном случае этот термин означает реальную опцию linemode (RFC 1184). Эта опция обсуждается клиентом и сервером и корректирует все недостатки в режиме строка за один раз.

С точки зрения безопасности протокол telnet уязвим для любого вида атак, к которым уязвим его транспорт, т.е. протокол TCP. В протоколе не предусмотрено использование ни шифрования, ни проверки подлинности данных. Поэтому telnet можно использовать в полностью контролируемой сети или с применением защиты на сетевом уровне (различные реализации виртуальных частных сетей). По причине ненадёжности от telnet как средства управления операционными системами давно отказались.

Иногда клиенты telnet используются для доступа к другим символьно-ориентрованным протоколам на основе транспорта TCP (HTTP, IRC, SMTP, POP3 и прочим). Однако, использование клиента telnet в этом качестве может привести к ошибкам, связанным с неправильной трактовкой сервером опций протокола.

Rlogin

Протокол rlogin (RFC 1282, порт сервера – 513) позволяет пользователям рабочих станций UNIX подключаться к удаленным серверам UNIX через сеть Internet и работать так же, как при прямом подключении терминала к машине. Помимо rlogin существуют еще несколько подобных протоколов: rsh (remote shell), rcp (remote copy). Утилиты rlogin, rsh и rcp часто объединяют под общим названием r-команд.

Впервые появившаяся в составе 4.2BSD UNIX, программа rlogin (и остальные r-команды) одно время была исключительно популярной в этой среде. В качестве средства терминального доступа rlogin очень похожа на telnet, но из-за тесной интеграции с ОС нашла ограниченное применение в других системах.

В rlogin отсутствуют многие опции, свойственные telnet, в частности режим согласования параметров между клиентом и сервером. Однако rlogin предусматривает хотя бы минимальные средства защиты на основе доверительных отношений между хостами: на сервере rlogin в специальных системных файлах (обычно /etc/hosts.equiv и $HOME/.rhosts) администратор может перечислить компьютеры, доступ с которых к данному серверу будет разрешен без пароля.

Пользователи других компьютеров (не перечисленных в этих файлах) могут войти на сервер лишь после ввода пароля (который как и в telnet передается в открытом виде). Но, доверительные отношения между хостами тоже не панацея, и могут устанавливаться лишь в изолированных сетях. Дело в том, что такие техники несанкционированного доступа, как подмена IP-адресов (IP-spoofing) и доменных имен (DNS-spoofing), делают r-сервисы в Интернет незащищенными. Поэтому современные дистрибутивы UNIX-подобных ОС включают не фактические r-команды, а замещающие ссылки на их SSH-аналоги: scp, sftp и др.(см. man rlogin в Ubuntu, выводящий руководство по OpenSSH).

SSH (Secure Shell)

SSH — безопасный протокол дистанционного управления компьютером. Основная спецификация – RFC 4251. The Secure Shell (SSH) Protocol Architecture, входящий порт – 22. По сравнению с протоколами telnet и rlogin, ssh отличается, в первую очередь, высокой защищенностью за счет поддержки криптостойких алгоритмов шифрования и рядом дополнительных возможностей.

SSH позволяет не только использовать защищенную оболочку на удаленном хосте, но и туннелировать графический интерфейс (X11 forwarding), превращая клиентов, использующих X-Window System, в графические терминалы. SSH также способен (при надлежащем конфигурированиии) передавать через безопасный канал любой другой сетевой протокол – port forwarding. Криптографическая защита протокола SSH не фиксирована, возможен выбор различных алгоритмов шифрования.

Согласно Указу Президента Российской Федерации № 334 от 03.04.95 физическим лицам и организациям, включая государственные, частные и акционерные, запрещена эксплуатация систем криптографии, не прошедших сертификации в ФАПСИ. А SSH (а иже с ним PGP) является именно такой системой.

Не стоит думать, что нам пытаются запретить защищать конфиденциальную информацию: организации не только могут, но и обязаны защищать важную информацию. Только для этого они должны применять сертифицированные средства. Применяя свободное, но несертифицированное ПО на основе ssh, SSL, PGP и т.п. следует помнить, что его использование чревато разбирательством со стороны спецслужб.

Сервис SSH использует по умолчанию порт 22 и объединяет протоколы трех уровней:

  • Протокол аутентификации (The Secure Shell (SSH) Authentication Protocol, RFC 4252) — этот уровень предоставляет несколько механизмов для аутентификации пользователя: здесь может использоваться традиционная парольная аутентификация, аутентификация, основанная на публичном ключе и т.д.

  • Протокол транспортного уровня (The Secure Shell (SSH) Transport Layer Protocol, RFC 4253) — обеспечивает взаимодействие алгоритма и обмен ключами. Обмен ключами позволяет аутентифицировать сервер и создать криптографически защищённое соединение: обеспечивая целостность, конфиденциальность и дополнительное сжатие.

  • Протокол соединения (The Secure Shell (SSH) Connection Protocol, RFC 4254) — создает безопасный (шифруемый) канал, представляя его в виде нескольких логических каналов, которые используются для различных целей (различных видов служб).

  • Поддержка SSH реализована во всех UNIX системах и на большинстве из них в типовую поставку включено как клиентское, так и серверное ПО (см. man ssh). Для не-UNIX систем имеются как платное, так и бесплатное клиентское ПО (SecureCRT, putty). Серверное ПО – платное (X-Window System).

Практически все задачи управления UNIX могут выполняться в текстовом режиме, однако администраторы нередко предпочитают графический интерфейс, как более удобный. Вдобавок, некоторыми приложениями UNIX можно управлять только в графической среде. Программное обеспечение X-server, отвечающее за вывод графической информации, имеется для множества платформ, включая DOS, Windows, Macintosh, UNIX и т.д.

Следует иметь в виду, что применение X Window System предполагает наличие достаточно большой пропускной способности сети. Система прекрасно работает в локальных сетях, но очень медленно — по глобальным каналам. Поэтому при использовании X Window System на домашнем компьютере администратора управление лучше осуществлять через терминальные утилиты наподобие xterm, а не посредством графических утилит.

При подключении к серверу UNIX (на котором запускаются клиенты X11) аутентификация может осуществляться двумя методами: через терминальные утилиты (telnet, rlogin и т. п.) и через менеджер дисплеев X (X Display Manager, xdm). В первом варианте передачи пароля в открытом виде можно избежать, применяя вместо telnet и rlogin уже упоминавшиеся программы ssh и OTP. В случае X Display Manager пароли по умолчанию передаются в открытом виде. Поэтому при удаленном управлении сервером UNIX по общедоступным сетям xdm пользоваться не стоит.

Очень осторожно администраторы должны подходить к вопросу использования сервера UNIX в качестве сервера X (т. е., говоря понятным языком, к запуску графической оболочки X11 на сервере UNIX). X Window System устроена так, что пользователь может со своей машины запустить клиента X на удаленном сервере X и перехватывать на нем ввод/вывод информации. В результате злоумышленник получает возможность считывать конфиденциальную информацию с сервера X, включая пароли, вводимые пользователем на сервере X (хотя эмулятор терминала xterm позволяет блокировать перехват пароля, этой возможностью редко кто пользуется).

На серверах X применяются две схемы аутентификации клиентов: по имени хоста и с помощью «магических плюшек» (MIT-MAGIC-COOKIE-1). При аутентификации по имени хоста на сервере X создаются системные файлы, где перечисляются хосты, откуда разрешено запускать клиентские программы X на данном сервере X. Но подобную защиту никак не назовешь достаточной, так как с помощью подмены IP-адресов или доменных имен злоумышленник может провести атаку на X11.

При использовании же схемы «магических плюшек» (их поддержка встроена в протокол XDMCP, на основе которого функционирует X Display Manager) аутентификация осуществляется на основании учетных записей пользователей. Чтобы иметь право запустить клиента на сервере X, пользователь в своем домашнем каталоге машины-клиента X11 должен иметь системный файл с записанным секретным кодом сервера X. Этот секретный код и называется магической плюшкой. Беда только в том, что плюшка передается по сети в открытом виде, поэтому данный метод также вряд ли можно считать безопасным.

В X Window System 11 Release 5 добавлены еще две схемы (XDM-AUTHORIZATION-1 и SUN-DES-1), напоминающие схему MIT-MAGIC-COOKIE-1, но использующие алгоритм шифрования DES. Однако из-за экспортных ограничений такие схемы в комплект поставки X Window System не включают. Исходя из вышеприведенных соображений, запускать серверное ПО X11 на сервере UNIX можно лишь в том случае, когда запрещен доступ клиентов X11 с других компьютеров.

Remote Desktop Protocol

RDP (англ. Remote Desktop Protocol, протокол удалённого рабочего стола) — открытый протокол прикладного уровня, разработанный Microsoft и изначально предназначенный для подключения графических терминалов к Windows Terminal Server. Клиенты существуют практически для всех версий Windows (включая Windows CE и Mobile), Linux, Free BSD, Mac OS X. По умолчанию используется порт TCP 3389. Офицальное название Майкрософт для клиентского ПО – Remote Desktop Connection или Terminal Services Client (TSC).

RDP-клиент, – Remote Desktop – позволяет вам, находясь на одном компьютере, удаленно управлять другим. Например, если вам нужно зайти в свой компьютер, находящийся в офисе, из дома (предположим, что вы заблаговременно настроили свой рабочий компьютер), то вы можете с помощью инструмента Remote Desktop получить доступ ко всем данным, находящимся на рабочем компьютере, включая файлы, приложения и сетевые соединения. Вы даже можете слышать звук, с которым открываются файлы (спрашивается: зачем? прим. aag).

Фактически Remote Desktop позволяет не только получать доступ к файлам удаленного компьютера, но и на самом деле видеть рабочий стол таким, какой он есть на удаленном компьютере. Более того, если удаленный компьютер работает в операционной системе Windows 2000 или .NET Server, то на нем могут удаленно работать несколько пользователей одновременно.

Технология Terminal Services является основой для работы удаленного помощника , который позволяет вашему другу или работнику технической поддержки устанавливать соединение с вашим компьютером, видеть ваш рабочий стол и управлять компьютером.

Для соединения инструмент Remote Desktop использует LAN, виртуальную частную сеть (VPN) или интернет-соединение. Работа удаленного рабочего стола сильно зависит от скорости установленного соединения.

Remote Desktop поддерживает работу в двух режимах:

  • Remote Desktop (Удаленный рабочий стол) – подходит для использования в локальной сети и требует установки программного обеспечения на компьютере-клиенте.

  • Remote Desktop Web Connection (Интернет-подключение к удаленному рабочему столу) – требует на клиентской машине только наличия браузера Internet Explorer, но на сервере для нее необходимо установить и настроить большее количество программ.

Remote Desktop поддерживает 24-битные цвета – это позволяет варьировать качество картинки в широких пределах.

Переадресация ресурсов позволяет, например, использовать файловую систему удаленного компьютера в качестве сетевого ресурса общего доступа.

Переадресация звуков позволяет компьютеру-клиенту воспроизводить звуки, которые генерируются на компьютере-сервере. При проигрывании звуков Remote Desktop также учитывает пропускную способность полосы частот. Вместо того чтобы перегружать соединение звуковым сигналом при изменении пропускной способности, Remote Desktop снижает качество звука.

Remote Desktop-сервер и Remote Desktop-клиент пользуются общим буфером. Это позволяет им свободно обмениваться информацией.

Веб-технологии удаленного управления

Всемирная Паутина (World Wide Web) оказывает все большее влияние на средства управления сетевой средой. Уже сейчас многие маршрутизаторы, коммутаторы, сетевые принтеры допускают управление через web-браузеры.

Но список этот далеко не исчерпывается ими и Web вторгается и в сферу управления сетевыми ОС.

Вначале из Web можно было управлять лишь серверами HTTP и FTP, но этот список постоянно расширяется и охватывает теперь СУБД (например, phpMyAdmin как веб-интерфейс к СУБД MySQL), файловые системы, межсетевые экраны, сетевые службы DNS, DHCP и многое другое (пример – Webmin для управления UNIX-подобными системами).

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

Методы удаленного доступа к Linux

Часть из рассматриваемых способов удаленного подключения работает только в том, случае, если установлен GUI-интерфейс.

OpenSSH

OpenSSH — это бесплатный SSH-сервер, дающий возможность интерактивного управления сервером. Для установки SSH на сервер воспользуемся встроенным в Ubuntu пакетным менеджером apt:

# sudo apt install openssh-server -y

В большинстве дистрибутивов OpenSSH-сервер уже присутствует в системе и его установка не требуется. В случае отсутствия OpenSSH, вышеуказанная команда выполнит установку.

Теперь добавим SSH-сервер в автозагрузку. При следующем запуске сервера, операционная система выполнит автоматический запуск SSH-сервера. Как и в случае с другими сервисами systemd позволяет управлять параметрами запуска, автозагрузки и рестарта демона OpenSSH. Включим автозапуск:

# sudo systemctl enable ssh

В результате получим:

Проверим работоспособность утилиты:

# ssh localhost

И убедимся, что всё корректно работает:

Как настроить SSH

Настройка SSH на Ubuntu необходима для улучшения защищенности системы. Например, можно отключить возможность входа от имени пользователя root или изменить порт подключения со стандартного 22 на произвольный. Лучше использовать порты из верхнего диапазона (50000-65000). Напомним, что в стеке протоколов TCP/IP доступно 65536 портов.

Настройка выполняется выполняется в конфигурационном файле. Перед его модификацией, создадим резервную копию.

# sudo cp /etc/ssh/sshd_config
/etc/ssh/sshd_config.factory-defaults

Вот теперь можно менять порт. Все изменения конфигурации SSH выполняются в файле /etc/ssh/sshd_config. Откроем его на редактирование:

# sudo vi /etc/ssh/sshd_config

*Файл конфигурации sshd в дистрибутиве ALT Linux расположен в каталоге etc/openssh/sshd_config

Раскомментируем строку Port 22 и изменим значение на 55555. Но мы должны вас предостеречь, боты прежде всего сканируют порты с одинаковыми цифрами, поэтому в промышленных средах лучше использовать номер порта с отличными друг от друга цифрами.

Далее нужно отключить возможность входа на сервер учетной записи суперпользователя (root) и добавить возможность входить через ключи. Для этого изменим значения параметров PermitRootLogin на no и PubkeyAuthentication на yes (Пока не стоит, это далее):

После этого следует перезагрузить демон SSH. Соединение при этом будет разорвано и подключиться можно будет через новый порт и пользовательскую учетную запись (она должны быть предварительно создана).

sudo systemctl restart ssh

Переподключимся от обычной учетной записи и по другому порту:

ssh -p 55555 ansible@95.213.154.235

После успешного подключения можно продолжать работу с сервером.

Как создать пару ключей RSA

Еще один способ аутентификации на сервере — пара ключей RSA: открытый и закрытый. Открытый хранится на сервере, к которому будет выполняться подключение, а закрытый на удаленном компьютере (или другом сервере) откуда выполняется подключение.

На схеме ниже иллюстрация безопасного обмена ключами между Алисой и Бобом. Злоумышленник Ева может читать сообщения, если они не зашифрованы. Здесь Алиса или Боб шифруют сообщение при помощи открытого ключа принимающей стороны, которая его дешифрует при помощи своего закрытого ключа.

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

# ssh-keygen -t rsa

Команду нужно выполнять на своей рабочей станции от имени пользователя, который будет в дальнейшем подключаться к удаленному компьютеру. Путь к хранению ключей можно оставить по умолчанию:

Ключи созданы, можно переходить к следующему шагу — копированию открытого ключа на удаленный сервер. Предварительно убедитесь, что на том сервере создана учетная запись, от имени которой вы будете подключаться.

Как скопировать открытый ключ на сервер

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

# ssh-copy-id -i ~/.ssh/id_rsa.pub antoniusfirst@95.213.154.235

В этом примере 95.213.154.235 — это IP-адрес удаленного сервера. После ввода пароля, ключ копируется папку .ssh домашней директории пользователя.

# ssh antoniusfirst@95.213.154.235

Вывод обеих команд на скриншоте ниже.

Как пройти аутентификацию на сервере через созданный ключ

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

# ssh antoniusfirst@95.213.154.235

Если подключение по SSH будет успешным — все настройки были выполнены корректно.

Как выполнить отключение аутентификации по паролю

Для отключения возможности входа по паролю необходимо в файле /etc/ssh/sshd_config отредактировать значение PasswordAuthentication и присвоить no.

После изменения настроек перезагружаем службу SSH:

# sudo systemctl restart ssh

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

При этом подключение при помощи ключа будет успешным.

Отключение доступа паролю — верная стратегия повышения безопасности сервера. Особенно в публичных облаках. Однако, если ключ будет утерян, это станет серьезной проблемой. Поэтому важно его хранить в надежном месте или пользоваться специализированными инструментами, например, аппаратным устройством Yubikey.

Как настроить стандартный firewall

В Ubuntu есть встроенный фаервол Netfilter, который может управляться как непосредственно вызовом утилиты iptables с параметрами так и специальной утилитой UFW (Uncomplicated Firewall). Мы разберем оба варианта.

Iptables на нашем демо-стенде уже установлен, но если в вашем дистрибутиве его нет — можно воспользоваться пакетным менеджером apt:

# sudo apt-get install iptables

При работе с iptables можно настроить три типа правил: INPUT — для входящих соединений, OUTPUT — для исходящих и forward для транзитных (используется для маршрутизаторов). Для сервера актуальны первые два.

При обработке пакетов возможно выполнение следующих действий: ACCEPT — разрешить прием пакета, DROP — удалить пакет, REJECT — отклонить пакет и отправил уведомление об отклонении отправителю, LOG — записать пакет в лог и QUEUE — отправить пакет приложению.

В iptables доступны следующие функции управления:

  • A — добавить правило в цепочку;

  • С — проверить все правила;

  • D — удалить правило;

  • I — вставить правило с нужным номером;

  • L — вывести все правила в текущей цепочке;

  • S — вывести все правила;

  • F — очистить все правила;

  • N — создать цепочку;

  • X — удалить цепочку;

  • P — установить действие по умолчанию.

Например, чтобы посмотреть настроенные правила можно выполнить команду

# sudo iptables -L

Теперь попробуем заблокировать все пакеты от узла 10.10.10.10:

# sudo iptables -A INPUT -s 10.10.10.0/24 -j DROP

При помощи комбинаций перечисленных выше опций можно настроить любую требуемую логику работы с сетевыми пакетами.

Если перечисленные выше опции показались сложными, можно упростить задачу настройки фаервола и воспользоваться утилитой ufw. Перед началом работы, установим ее при помощи пакетного менеджера apt:

# sudo apt install ufw -y

После установки можно начинать работать с правилами. Разрешим все исходящие соединения и запретим все входящие:

# sudo ufw default deny incoming
# sudo ufw default allow outgoing

В выводе увидим:

В примерах выше мы меняли порт для доступа по SSH на 55555. Создадим правило для доступа по этому порту:

# sudo ufw allow 55555

В выводе получим:

Теперь включим сам фаервол.

# sudo ufw enable

Обратите внимание на предупреждение системы об отключении SSH-подключений, если вдруг вы забыли добавить соответствующее правило. Но мы его добавили, поэтому смело включаем фаервол.

После включения фаервола, проверим его настройки командой:

# sudo ufw status verbose

В выводе увидим:

Дополнительно можно настроить доступ с определенного IP-адреса (или диапазона адресов), на определенный порт.

# sudo ufw allow from 95.213.154.235 to any port 55555

При помощи правил UFW можно также применять правила к определенным сетевым интерфейсам сервера.

Как настройки подключения по SSH влияют на безопасность

В этом разделе разберем основные настройки для повышения уровня безопасности SSH. Все настройки выполняются в уже известном конфигурационном файле /etc/ssh/sshd_config.

Первая настройка — проверка соответствия DNS-имени IP-адресу клиента. За это отвечает параметр UseDNS.

# UseDNS yes

Следующий шаг к безопасности — запрет пустых паролей. Задается в параметре PermitEmptyPasswords.

# PermitEmptyPasswords no

Дополнительно можно ограничить количество неудачных попыток подключения:

# MaxAuthTries 3

Еще один подход к ограничению несанкционированных подключений — задание пользователей и групп, которым разрешен доступ по SSH. Они перечисляются в параметрах AllowUsers и AllowGroups.

# AllowUsers User1, User2, User3
# AllowGroups Group1, Group2, Group3

Дополнительно, можно задать время, в течении которого система ожидает от пользователя ввода пароля. По умолчанию это две минуты, но лучше уменьшить до 30 секунд.

# Login GraceTime 30

Отключение пользователя при бездействии позволит предотвратить доступ злоумышленника, если пользователь вдруг отлучился от своего рабочего места. Значение задается в секундах

# ClientAliveInterval 300

Мы перечислили основные параметры для повышения безопасности SSH-соединений, однако, можно выполнять и более тонкую настройку. Полный список команд можно найти в официальной документации.

Нельзя не упомянуть про эффективный инструмент борьбы с попытками аутентификации — утилите fail2ban. Это сервис, который читает лог безопасности и блокирует злоумышленников по IP. Штатно устанавливается при помощи apt:

# sudo apt install fail2ban

После установки появляются два конфигурационных файла: /etc/fail2ban/fail2ban.conf и /etc/fail2ban/jail.conf. Первый отвечает за настройки запуска fail2ban, а второй за настройки защиты конкретных сервисов.

Заключение

Мы рассказали об основных настройках протокола SSH, которые помогут уберечь Ubuntu-сервер от несанкционированного доступа. Особенно важно их использовать при расположении сервера в публичных облаках с публичным IP-адресом. На скриншоте ниже вы видите журнал безопасности системы, на которой мы проводили перечисленные в этой статье настройки. В нем видно, что попытки авторизаций под разными пользователями (root, system и другими) происходят регулярно.

Перечисленных настроек достаточно для обеспечения базовой безопасности сервера и предотвращения его вовлечения в бот-сети.

RDP

На виртуальном сервере, в зависимости от OS нужно произвести следующие действия. Debian:

$ apt-get install xrdp
$ systemctl enable xrdp
$ systemctl start xrdp

CentOS:

$ yum install epel-release
$ yum install xrdp tigervnc-server tigervnc-server-module
$ chcon -t bin_t /usr/sbin/xrdp
$ chcon -t bin_t /usr/sbin/xrdp-sesman
$ firewall-cmd --zone=public --add-port=3389/tcp --permanent
$ firewall-cmd --zone=public --add-port=3389/udp --permanent
$ firewall-cmd --reload
$ systemctl enable xrdp
$ systemctl start xrdp

XDMCP:

$ vi /etc/gdm/custom.conf

[security]
AllowRemoteRoot=true
DisallowTCP=false
 
[xdmcp]
Enable=true
MaxSessions=30

Далее, если вы используете Windows, подключаемся через встроенный RDP-клиент, Remote Desktop Connection (Подключение к удаленному рабочему столу).

Стандартный порт 3389. Для Linux есть масса клиентов которые можно установить из репозиториев: freerdp и remmina, gnome-rdp, vinagre и т.п. Для Mac OS: Также можно пробросить RDP-шный трафик через SSH-туннель. Для этого нужно поправить конфигурационный файл xrdp:

$ vi /etc/xrdp/xrdp.ini

В секцию [globals] нужно добавить строку: address=127.0.0.1

$ systemctl restart xrdp

Проверить, что всё правильно, можно так:

$ nmap -p 3389 [IP]

Starting Nmap 6.47 ( http://nmap.org ) at 2016-10-04 13:07 MSK
Nmap scan report for unspecified.mtw.ru ([IP])
Host is up (0.0087s latency).
PORT     STATE  SERVICE
3389/tcp closed ms-wbt-server

Затем если вы используете cygwin или mingw, linux или mac os:

ssh root@[IP] -L 3389:localhost:3389

Если PuTTY: Запустите PuTTY. В древовидном меню слева Connection → SSH → Tunnels. Далее добавляем новый Forwarded Port (Source port: 3389, Destination: localhost:3389). Нажимаем Add.

Далее следуете в секцию Session. Вводите IP вашего сервера в поле Host Name (or IP address). Нажимаете кнопку Open, вводите пароль для подключения по SSH.

Далее для Windows:

VNC

Клиент: Для Windows:

Для Linux:

  1. Можно использовать вышеупомянутый клиент: remmina

  2. Если в браузере хотите: novnc — HTML5 VNC client

  3. И ещё куча всяких разных: directvnc, gnome-rdp, krdc, xtightvncviewer, vinagre, xvnc4viewer

Для MAC OS: OS X предоставляет для этого встроенное приложение Screen Sharing. Можно также использовать Safari

vnc://yourserverip:5901

Сервер: На Вашей виртуальной машине установите VNC сервер:

$ apt-get install tightvncserver

Или

$ apt-get install vnc4server
$ yum install tigervnc-server

Если на Вашей системе работает файрвол необходимо открыть соответствующие порты. Пример для CentOS

$ firewall-cmd --zone=public --add-port=5901/tcp --permanent
$ firewall-cmd --zone=public --add-port=5901/udp --permanent
$ firewall-cmd --reload

Далее выполните:

$ vncpasswd
Password:
Verify:

При возникновении проблем с отображением иконок и шрифтов при использовании xfce4 по Ubuntu/Debian:

$ echo "export XKL_XMODMAP_DISABLE=1" >> ~/.vnc/xstartup

Если вы хотите, чтобы VNC-сервер стартовал автоматически, создайте файл:

$ vi /lib/systemd/system/vncsrv.service

Со следующим содержимым:

[Service]
Environment=RESOLUTION=800x600
Environment=COLOR=16
Environment=DISPLAY=1

[Unit]
Description=VNC Server

[Service]
Type=forking
ExecStart=/usr/bin/vncserver -depth ${DEPTH} -geometry ${RESOLUTION} :${DISPLAY}
ExecStop=/usr/bin/vncserver -kill :${DISPLAY}
ExecReload=/usr/bin/vncserver -kill :${DISPLAY} && /usr/bin/vncserver -depth ${DEPTH} -geometry ${RESOLUTION} :${DISPLAY}
User=root

[Install]
WantedBy=multi-user.target

Далее выполните:

systemctl daemon-reload
systemctl enable vncsrv.service
systemctl start vncsrv.service

Теперь можно подключиться, например, через UltraVNC. Для этого нужно запустить UltraVNC Viewer, в поле VNC Server записать [IP]::5901 (по-умолчанию: 5901, 5902 и т.п. для первого дисплея, второго и т.д. соответственно) и нажать на кнопку подключиться. Также можно пустить vnc-шный трафик через ssh-туннель. Для этого отредактируйте:

$ vi /lib/systemd/system/vncsrv.service

[Service]
Environment=RESOLUTION=800x600
Environment=COLOR=16
Environment=DISPLAY=1

[Unit]
Description=VNC Server

[Service]
Type=forking
ExecStart=/usr/bin/vncserver -depth ${DEPTH} -geometry ${RESOLUTION} :${DISPLAY} -localhost
ExecStop=/usr/bin/vncserver -kill :${DISPLAY}
ExecReload=/usr/bin/vncserver -kill :${DISPLAY} && /usr/bin/vncserver -depth ${DEPTH} -geometry ${RESOLUTION} :${DISPLAY} -localhost
User=root

[Install]
WantedBy=multi-user.target

Затем если вы используете cygwin или mingw, linux или mac os:

ssh root@[IP] -L 5901:localhost:5901

Если PuTTY: Запустите PuTTY. В древовидном меню слева Connection → SSH → Tunnels. Далее добавляем новый Forwarded Port (Source port: 5901, Destination: localhost:5901). Нажимаем Add.

Далее следуете в секцию Session. Вводите IP вашего сервера в поле Host Name (or IP address). Нажимаете кнопку Open, вводите пароль для подключения по SSH.

Затем открываете UltraVNC Viewer и в поле VNC Server вводите: localhost::5901 после чего подключаетесь.

Также можете попробовать другие VNC-сервера: x11vnc — фактически VNC-сервер (как vnc4server или tightvnc), но позволяет получать доступ к уже существующей X-сессии. Т.е. если Вы настроили графическую оболочку таким образом, что она запускается при старте системы, то можно использовать следующий вариант:

$ apt-get install x11vnc
$ x11vnc -storepasswd
$ x11vnc -usepw
$ x11vnc -xkb -noxrecord -noxfixes -noxdamage -display :0 -auth /var/run/lightdm/root/:0 -usepw &
$ disown -h %1

После подключения по VNC (на порт 5900) Вы должны увидеть тоже что и в «Аварийном режиме». Для старта x11vnc при запуске OS необходимо проделать следующее:

$ vi /lib/systemd/system/xvncsrv.service

Добавляем:

[Unit]
Description=X11VNC

[Service]
Type=forking
ExecStart=/usr/bin/x11vnc -xkb -noxrecord -noxfixes -noxdamage -display :2 -usepw
User=root

[Install]
WantedBy=graphical.target

Далее:

systemctl daemon-reload
systemctl enable xvncsrv.service
systemctl start xvncsrv.service

NX

Теперь немного поинтереснее. Одна замечательная компания NoMachine разработала отличный протокол NX на замену VNC. Клиенты для подключения по этому протоколу бесплатны, а официальное серверное ПО от NoMachine стоит много денег. В свое время, эта же компания поддерживала проект FreeNX работы на котором со временем затихли; текущая версия 0.7.2 от 2008-08-22. Но, к счастью, нашлись люди создавшие форк и назвавшие его x2go. К сожалению, x2go не совместим ни с NX от NoMachine, ни с freeNX. Так что клиент берем тут. Установка сервера на Debian (источник): Для примера поставим эту DE:

$ apt-get install fluxbox

Далее следуем инструкциям с официального сайта:

$ apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E
$ echo "deb http://packages.x2go.org/debian jessie main" > /etc/apt/sources.list.d/x2go.list
$ echo "deb-src http://packages.x2go.org/debian jessie main" >> /etc/apt/sources.list.d/x2go.list
$ apt-get update
$ apt-get install x2go-keyring && apt-get update
$ apt-get install x2goserver x2goserver-xsession

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

$ systemctl status x2goserver
● x2goserver.service - LSB: Start and stop the X2Go daemon
   Loaded: loaded (/etc/init.d/x2goserver)
   Active: active (running) since Tue 2016-10-11 22:05:51 MSK; 30min ago
...

А теперь важный момент, подключиться без этого фикса не получится! Нужно найти в файле .profile строку «mesg n» и заменить её на «tty -s && mesg n».

$ vi .profile

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

$ whereis startfluxbox

Установка сервера на Ubuntu:

$ apt-get install xfce4 xfce4-terminal
$ add-apt-repository ppa:x2go/stable
$ apt-get update
$ apt-get install x2goserver x2goserver-xsession

А теперь важный момент, подключиться без этого фикса не получится! Нужно найти в файле .profile строку «mesg n || true» и заменить её на «tty -s && mesg n».

$ vi .profile

Установка сервера на CentOS:

$ yum install epel-release
$ yum install x2goserver x2goserver-xsession

Клиент для линукс ставится из вышеприведенных репозиториев следующей командой:

$ apt-get install x2goclient

Для Windows — скачиваем, ставим, запускаем. По той же ссылке, приведенной выше, есть клиент для OS X. Запускаем клиент:

В настройках сессии указываем: в поле Host — IP вашего сервера, в поле Login — root, порт оставляем как есть, session type — тот GUI который ставили.

Как вы можете видеть, есть возможность аутентификации по ключу. В общем много всякого. Посмотрите сами. И звук можно через PulseAudio выводить. После нажатия Ok вы увидите вот такие вот очаровательные штучки, на которые нужно нажать для получения запроса на ввод пароля и подключения к выбранной сессии:

Замечание: обратите внимание, что в списке нет Вашего любимого FluxBox’а поэтому путь к нему приходится прописывать руками. Важной возможностью x2go является возможность запуска любого графического приложения вообще без установки DE. Для этого в настройках сессии нужно в секции session type нужно выбрать пункт single application и выбрать выполняемое приложение или ввести путь к программе которую следует запустить. В этом случае установка ПО на сервер будет выглядеть следующим образом. В случае с Ubuntu:

$ add-apt-repository ppa:x2go/stable
$ apt-get update
$ apt-get install x2goserver x2goserver-xsession

А теперь важный момент, подключиться без этого фикса не получится! Нужно найти в файле .profile строку «mesg n || true» и заменить её на «tty -s && mesg n».

$ vi .profile
$ apt-get install firefox xterm

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

Или так; тогда просто откроется окно терминала:

Ниже вы можете видеть скриншот окна статуса текущей сессии. Оранжевыми цифрами отмечены кнопки:

  1. «Suspend session» — после нажатия на эту кнопку соединение будет разорвано, но сессия останется и будет ожидать повторного подключения. Все запущенные вами на сервере приложения продолжат свою работу;

  2. «Terminate session» — после нажатия подключение к серверу будет разорвано, а запущенные вами на сервере приложения будут завершены.

TeamViewer

Последний способ удаленного доступа к рабочему столу. Установка на Ubuntu:

$ apt-get update
$ apt-get install lubuntu-desktop
$ reboot
$ dpkg --add-architecture i386
$ apt-get update
$ wget http://download.teamviewer.com/download/teamviewer_i386.deb
$ dpkg -i teamviewer_i386.deb
$ apt-get -f install
$ teamviewer --passwd [PASSWD]

Установка на Debian:

$ apt-get update
$ apt-get install lxde lightdm
$ reboot
$ dpkg --add-architecture i386
$ apt-get update
$ wget http://download.teamviewer.com/download/teamviewer_i386.deb
$ dpkg -i teamviewer_i386.deb
$ apt-get -f install
$ teamviewer --passwd [PASSWD]

Установка на CentOS:

$ yum groupinstall "X Window system"
$ yum install epel-release
$ yum install fluxbox xterm lightdm
$ systemctl set-default graphical.target
$ reboot
$ curl -o TeamViewer_Linux_PubKey.asc -Lk http://www.teamviewer.com/link/?url=354858
$ rpm --import TeamViewer_Linux_PubKey.asc
$ curl -LOk http://download.teamviewer.com/download/teamviewer.i686.rpm
$ yum install teamviewer.i686.rpm
$ teamviewer --passwd [PASSWD]

Также необходимо принять лицензионное соглашение TeamViewer’а, это можно сделать с помощью «Аварийного режима», либо добавить следующие строки в конец файла /opt/teamviewer/config/global.conf:

$ echo "[int32] EulaAccepted = 1" >> /opt/teamviewer/config/global.conf
$ echo "[int32] EulaAcceptedRevision = 6" >> /opt/teamviewer/config/global.conf
$ teamviewer --daemon restart

Следующая команда покажет состояние демона TeamViewer’а и необходимый для подключения девятизначный TeamViewer ID:

$ teamviewer --info

После запуска клиента скачанного тут, нужно ввести TeamViewer ID в поле Partner UD и нажать на кнопку «Connect to partner». Далее TeamViewer запросит пароль: [PASSWD].

Вместо заключения

Вот вроде бы и всё. Надеемся что эта статья поможет пользователям linux-серверов в настройке комфортного и удобного для них окружения.

Last updated