Linux Admin — Удаленное управление

Говоря об удаленном управлении в CentOS в качестве администратора, мы рассмотрим два метода:

• Консольное управление
• Управление GUI

Удаленное управление консолью

Удаленное управление консолью означает выполнение задач администрирования из командной строки через службу, такую ​​как ssh. Чтобы эффективно использовать CentOS Linux, как администратор, вам нужно хорошо разбираться в командной строке. Linux в своей основе был разработан для использования с консоли. Даже сегодня некоторые системные администраторы предпочитают мощь команды и экономят деньги на оборудовании, выполняя обычные Linux-боксы без физического терминала и без установленного графического интерфейса.

Удаленное управление GUI

Удаленное управление графическим интерфейсом обычно выполняется двумя способами: либо удаленным сеансом X-Session, либо протоколом уровня приложения GUI, таким как VNC. У каждого есть свои сильные и слабые стороны. Однако по большей части VNC является лучшим выбором для администрирования. Это позволяет графическое управление из других операционных систем, таких как Windows или OS X, которые изначально не поддерживают протокол X Windows.

Использование удаленных сеансов X является родным для оконных менеджеров X-Window и DesktopManager, работающих на X. Однако вся архитектура сеансов X в основном используется в Linux. Не каждый системный администратор будет иметь под рукой портативный компьютер Linux для установки удаленного сеанса X. Поэтому чаще всего используется адаптированная версия VNC Server.

Самыми большими недостатками VNC являются: VNC изначально не поддерживает многопользовательскую среду, такую ​​как удаленные X-сеансы. Следовательно, для доступа GUI к конечным пользователям удаленные XSessions будут лучшим выбором. Однако в основном мы занимаемся удаленным администрированием сервера CentOS.

Мы обсудим настройку VNC для нескольких администраторов против нескольких сотен конечных пользователей с удаленными X-сессиями.

Создание основы для безопасности с помощью SSH для удаленного консольного доступа

Теперь ssh или Secure Shell являются стандартом для удаленного администрирования любого сервера Linux. SSH в отличие от telnet использует TLS для аутентификации и сквозного шифрования сообщений. При правильной настройке администратор может быть уверен, что и его пароль, и сервер доверены удаленно.

Перед настройкой SSH, давайте немного поговорим о базовой безопасности и наименьшем общем доступе. Когда SSH работает на порте по умолчанию 22; скорее, чем позже, вы начнете подвергаться атакам методом перебора словаря по общим именам пользователей и паролям. Это только идет с территорией. Независимо от того, сколько хостов вы добавляете в свои запрещенные файлы, они будут ежедневно приходить с разных IP-адресов.

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

• Никогда не используйте общее имя пользователя или пароль. Имена пользователей в системе не должны быть системными по умолчанию или связаны с адресом электронной почты компании, например: [email protected]

• Корневой доступ или административный доступ не должны быть разрешены через SSH. Используйте уникальное имя пользователя и su для root или учетной записи администратора после аутентификации через SSH.

• Политика паролей обязательна: сложные пароли пользователей SSH, такие как: «Это и есть, и GUD & P @ ssW0rd & 24 & me». Меняйте пароли каждые несколько месяцев, чтобы исключить вероятность атак с использованием грубой силы.

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

• Смотрите ваши логи ежедневно. Как системный администратор, посвящайте журналам системы и безопасности каждое утро не менее 30-40 минут. Если вас спросят, дайте всем знать, что у вас нет времени не проявлять инициативу. Эта практика поможет изолировать предупреждающие знаки до того, как проблема окажется перед конечными пользователями и прибылью компании.

Никогда не используйте общее имя пользователя или пароль. Имена пользователей в системе не должны быть системными по умолчанию или связаны с адресом электронной почты компании, например: [email protected]

Корневой доступ или административный доступ не должны быть разрешены через SSH. Используйте уникальное имя пользователя и su для root или учетной записи администратора после аутентификации через SSH.

Политика паролей обязательна: сложные пароли пользователей SSH, такие как: «Это и есть, и GUD & P @ ssW0rd & 24 & me». Меняйте пароли каждые несколько месяцев, чтобы исключить вероятность атак с использованием грубой силы.

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

Смотрите ваши логи ежедневно. Как системный администратор, посвящайте журналам системы и безопасности каждое утро не менее 30-40 минут. Если вас спросят, дайте всем знать, что у вас нет времени не проявлять инициативу. Эта практика поможет изолировать предупреждающие знаки до того, как проблема окажется перед конечными пользователями и прибылью компании.

Примечание о безопасности Linux. Любой, кто интересуется администрированием Linux, должен активно следить за текущими новостями и технологиями Cyber-Security. В то время как мы в основном слышим о взломе других операционных систем, небезопасный Linux-пакет является востребованным сокровищем для киберпреступников. Обладая мощью Linux на высокоскоростном интернет-соединении, опытный киберпреступник может использовать Linux для усиления атак на другие операционные системы.

Установите и настройте SSH для удаленного доступа

Шаг 1 — Установите SSH Server и все зависимые пакеты.

[root@localhost]# yum -y install openssh-server 
'Loaded plugins: fastestmirror, langpacks 
Loading mirror speeds from cached hostfile 
* base: repos.centos.net 
* extras: repos.dfw.centos.com 
* updates: centos.centos.com 
Resolving Dependencies 
   --> Running transaction check 
   ---> Package openssh-server.x86_64 0:6.6.1p1-33.el7_3 will be installed 
   --> Finished Dependency Resolution 
Dependencies Resolved

Шаг 2. Сделайте безопасное регулярное использование для доступа к оболочке.

[root@localhost ~]# useradd choozer 
[root@localhost ~]# usermod -c "Remote Access" -d /home/choozer -g users -G 
wheel -a choozer

Примечание. Мы добавили нового пользователя в группу wheel, что позволило ему войти в root после аутентификации доступа SSH. Мы также использовали имя пользователя, которого нет в общих списках слов. Таким образом, наша учетная запись не будет заблокирована при атаке по SSH.

Файл с настройками конфигурации для сервера sshd — это / etc / ssh / sshd_config .

Части, которые мы хотим редактировать изначально:

LoginGraceTime 60m
PermitRootLogin no

Шаг 3 — Перезагрузите SSH-демон sshd .

[root@localhost]# systemctl reload sshd

Рекомендуется установить льготный период выхода из системы на 60 минут. Некоторые сложные задачи администрирования могут превышать значение по умолчанию, равное 2 минутам. Нет ничего более расстраивающего, чем тайм-аут сеанса SSH при настройке или исследовании изменений.

Шаг 4 — Давайте попробуем войти в систему, используя учетные данные root.

bash-3.2# ssh centos.vmnet.local 
[email protected]'s password:   
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Шаг 5 — Мы больше не можем входить удаленно через ssh с правами root . Итак, давайте войдем в нашу непривилегированную учетную запись пользователя и su в корневой учетной записи.

bash-3.2# ssh [email protected]
[email protected]'s password:
[choozer@localhost ~]$ su root
Password:

[root@localhost choozer]#

Шаг 6 — Наконец, давайте удостоверимся, что служба SSHD загружается при загрузке, а firewalld разрешает внешние соединения SSH.

[root@localhost]# systemctl enable sshd

[root@localhost]# firewall-cmd --permanent --add-service=ssh 
success

[root@localhost]# firewall-cmd --reload 
success
 
[root@localhost]#
 

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

Настройте VNC для удаленного администрирования CentOS

Есть несколько способов включить удаленное администрирование CentOS через VNC в CentOS 6-7. Самый простой, но самый ограниченный способ — это просто использовать пакет, называемый vino . Vino — это приложение для подключения к виртуальной сети для Linux, разработанное на платформе Gnome Desktop. Следовательно, предполагается, что установка была завершена с помощью Gnome Desktop. Если Gnome Desktop не был установлен, сделайте это, прежде чем продолжить. По умолчанию Vino будет установлен с графическим интерфейсом Gnome.

Чтобы настроить совместное использование экрана с Vino в Gnome, мы хотим перейти в системные настройки CentOS для совместного использования экрана.

Applications->System Tools->Settings->Sharing

Примечания к настройке VNC Desktop Sharing —

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

• Включить Требуется пароль — это отдельно от пароля пользователя. Он будет контролировать доступ к виртуальному рабочему столу и по-прежнему требовать пароль пользователя для доступа к заблокированному рабочему столу (это полезно для безопасности).

• Переадресация портов UP & P: если доступно, оставьте отключенным — Переадресация портов UP & P будет отправлять запросы Universal Plug and Play для устройства уровня 3, чтобы автоматически разрешать VNC-соединения с хостом. Мы не хотим этого.

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

Включить Требуется пароль — это отдельно от пароля пользователя. Он будет контролировать доступ к виртуальному рабочему столу и по-прежнему требовать пароль пользователя для доступа к заблокированному рабочему столу (это полезно для безопасности).

Переадресация портов UP & P: если доступно, оставьте отключенным — Переадресация портов UP & P будет отправлять запросы Universal Plug and Play для устройства уровня 3, чтобы автоматически разрешать VNC-соединения с хостом. Мы не хотим этого.

Убедитесь, что Vino прослушивает порт VNC 5900.

 
[root@localhost]# netstat -antup | grep vino 
tcp        0        0 0.0.0.0:5900        0.0.0.0:*        LISTEN        4873/vino-server
tcp6       0        0 :::5900                :::*          LISTEN        4873/vino-server
   
[root@localhost]#

Давайте теперь настроим наш брандмауэр, чтобы разрешить входящие соединения VNC.

[root@localhost]# firewall-cmd --permanent --add-port=5900/tcp 
success

[root@localhost]# firewall-cmd --reload 
success

[root@localhost rdc]#

Наконец, как вы можете видеть, мы можем подключить наш CentOS Box и администрировать его с помощью клиента VNC в Windows или OS X.

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

После ввода пароля общего доступа к экрану VNC мы также должны ввести пароль пользователя для доступа к заблокированному рабочему столу.

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

Настройте SSH-туннель через VNC

Настройка туннеля SSH обеспечит уровень шифрования SSH для туннелирования через VNC-соединение. Еще одна замечательная особенность — он использует сжатие SSH, чтобы добавить еще один уровень сжатия в обновления экрана графического интерфейса VNC. Более безопасный и быстрый способ всегда полезен при администрировании серверов CentOS!

Итак, от вашего клиента, который будет инициировать соединение VNC, давайте настроим удаленный туннель SSH. В этой демонстрации мы используем OS X. Сначала нам нужно sudo -s для root .

bash-3.2# sudo -s 
password:

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

bash-3.2#

Теперь давайте создадим наш SSH-туннель .

ssh -f [email protected] -L 2200:192.168.1.143:5900 -N

Давайте разберем эту команду —

• ssh — запускает локальную утилиту ssh

• -f — ssh должен запускаться в фоновом режиме после полного выполнения задачи

• [email protected] — удаленный пользователь ssh на сервере CentOS, на котором размещены службы VNC

• -L 2200: 192.168.1.143: 5900 — Создать наш туннель [Локальный порт]: [удаленный хост]: [удаленный порт службы VNC]

• -N говорит SSH, что мы не хотим выполнять команду в удаленной системе

ssh — запускает локальную утилиту ssh

-f — ssh должен запускаться в фоновом режиме после полного выполнения задачи

[email protected] — удаленный пользователь ssh на сервере CentOS, на котором размещены службы VNC

-L 2200: 192.168.1.143: 5900 — Создать наш туннель [Локальный порт]: [удаленный хост]: [удаленный порт службы VNC]

-N говорит SSH, что мы не хотим выполнять команду в удаленной системе

bash-3.2# ssh -f [email protected] -L 2200:192.168.1.143:5900 -N
[email protected]'s password:

После успешного ввода пароля удаленного пользователя ssh создается наш ssh-туннель . Теперь о крутой части! Для подключения мы указываем наш VNC-клиент на локальный хост на порту нашего туннеля, в данном случае на порт 2200. Ниже приведена конфигурация на VNC-клиенте для ноутбука Mac —

И, наконец, наше удаленное VNC Desktop Connection!

Крутая вещь в SSH-туннелировании заключается в том, что его можно использовать практически для любого протокола. Туннели SSH обычно используются для обхода фильтрации выходных и входных портов провайдером, а также для трюков прикладного уровня IDS / IPS, избегая при этом мониторинга других сеансовых уровней.

• Ваш Интернет-провайдер может фильтровать порт 5900 для некоммерческих учетных записей, но разрешить SSH на порту 22 (или можно запустить SSH на любом порту, если порт 22 отфильтрован).

• IPS и IDS уровня приложения смотрят на полезную нагрузку. Например, общее переполнение буфера или SQL-инъекция. Сквозное шифрование SSH будет шифровать данные прикладного уровня.

Ваш Интернет-провайдер может фильтровать порт 5900 для некоммерческих учетных записей, но разрешить SSH на порту 22 (или можно запустить SSH на любом порту, если порт 22 отфильтрован).

IPS и IDS уровня приложения смотрят на полезную нагрузку. Например, общее переполнение буфера или SQL-инъекция. Сквозное шифрование SSH будет шифровать данные прикладного уровня.

SSH Tunneling — отличный инструмент в наборе инструментов администратора Linux для достижения цели. Однако, как администратор, мы хотим изучить возможность блокировки доступа менее привилегированных пользователей, имеющих доступ к SSH-туннелированию.

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

Это сложная тема, выходящая за рамки учебника начального уровня. Исследование по этой теме рекомендуется для тех, кто хочет достичь высших эшелонов администрирования CentOS Linux.

Используйте SSH Tunnel для удаленного X-Windows

Дизайн X-Windows в Linux действительно аккуратный по сравнению с Windows. Если мы хотим управлять удаленным Linux-модулем из другого Linux-модуля, мы можем воспользоваться механизмами, встроенными в X.

X-Windows (часто называемая просто «X») предоставляет механизм для отображения окон приложений, происходящих из одного блока Linux, в часть отображения X на другом блоке Linux. Таким образом, через SSH мы можем запросить пересылку приложения X-Windows на дисплей другого Linux-бокса по всему миру!

Чтобы запустить приложение X удаленно через ssh-туннель, нам просто нужно запустить одну команду —

[root@localhost]# ssh -X [email protected]

Синтаксис — ssh -X [пользователь] @ [хост], и на хосте должен быть запущен ssh с действительным пользователем.

Ниже приведен скриншот GIMP, работающего на рабочей станции Ubuntu через удаленный туннель XWindows ssh.

Довольно просто запускать приложения удаленно с другого сервера Linux или рабочей станции. Также можно запустить весь сеанс X и получить всю рабочую среду удаленно несколькими способами.

• XDMCP

• Безголовые программные пакеты, такие как NX

• Конфигурирование альтернативных дисплеев и рабочих столов в X и менеджерах рабочего стола, таких как Gnome или KDE

XDMCP

Безголовые программные пакеты, такие как NX

Конфигурирование альтернативных дисплеев и рабочих столов в X и менеджерах рабочего стола, таких как Gnome или KDE

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