Security root user

Security root user Техника

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

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

Cтатья не является “рецептом”, в котором надо выполнить все пункты. Некоторые пункты не нужны, если вы выполнили другие. Поэтому выберете только необходимые вам. Я же придерживаюсь следующего рецепта.

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

Содержание
  1. Устанавливайте обновления
  2. Замена стандартного порта SSH
  3. Config SSH
  4. Создание нового пользователя
  5. 🙅‍♂️ Запрет входа root пользователя
  6. Заблокировать пароль root
  7. 🔐 Используйте SSH ключ вместо пароля
  8. Создание ssh ключей
  9. Загрузка ключа на сервер
  10. 🙅‍♂️ Запрет авторизации по паролю
  11. Ограничить доступ пользователей по ssh
  12. Запрет X11 Forwarding
  13. Ограничение для попыток ввода пароля
  14. Установите таймаут подключения
  15. Отклонять подключение без пароля
  16. Бэкапы
  17. Заключение
  18. Мой коктейль
  19. Административные средства
  20. Разрешение доступа root
  21. Запрещение доступа root
  22. 4.4.2.1. Отключение оболочки root
  23. 4.4.2.2. Запрет входа root
  24. 4.4.2.3. Запрет входа root через SSH
  25. 4.4.2.4. Отключение root с помощью PAM
  26. Ограничение доступа root
  27. 4.4.3.1. Команда su
  28. 4.4.3.2. Команда sudo
  29. Оптимизация
  30. Антивирус
  31. Охлаждение
  32. Особенности
  33. ответов
  34. почему бы не запустить все root, все время?
  35. почему не дают возможность войти в систему как root?
  36. Почему у вас нет корневого входа?
  37. Другие вопросы по тегам:
  38. Похожие вопросы:

Устанавливайте обновления

Эффективность: 🛡️ 🛡️ 🛡️

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

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

Для Fedora, CentOS, RHEL команда на обновление выглядит так

sudo dnf upgrade

Для Ubuntu / Debian

sudo apt update && sudo apt upgrade -y

Замена стандартного порта SSH

Эффективность: 🛡️ 🛡️

Большинство ботов сканируют только дефолтный порт (22). Сменив его, вы защититесь от ботов работающих на дурака.

Перед сменой порта разберитесь, какой firewall стоит на вашей системе. Например на CentOS/RHEL это скорее всего firewalld.

Вам необходимо открыть новый порт для ssh, и закрыть старый. Например, если у вас установлен firewalld, а порт вы выбрали 58291, то команды для открытия порта будут такие:

firewall-cmd --zone=public --add-port=57622/tcp --permanent
firewall-cmd --reload

Для изменения порта нужно отредактировать файл /etc/ssh/sshd_config. В этой статье мы будем часто этим заниматься. Всякий раз, когда вам нужно отредактировать этот файл, используйте следующую команду:

sudo nano /etc/ssh/sshd_config

В открывшемся файле найдите следующую строку: #Port 22 Удалите решетку и измените номер порта, например на 58291. Номер не должен превышать 65535. Рекомендую выбрать пятизначное значение.

Также удостоверьтесь, что выбранное вами значение не конфликтует с другими сервисами в системе, например mysqld использует порт 3306, httpd — 80, ftpd — 21.

После этого необходимо перезапустить службу ssh:

sudo systemctl restart sshd

Для входа с использованием нового порта используйте следующий флаг:

ssh username@remote_host -p 58291

Config SSH

Чтобы не запоминать порты ко всем своим серверам, можно воспользоваться файлом ~.ssh/config. Создайте этот файл, если его нет на вашей локальной машине.

Security root user
Пример .ssh/config

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

ssh my_server

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

Создание нового пользователя

Эффективность: 🛡️ 🛡️ 🛡️

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

Root — это учётная запись, которая имеет доступ ко всем без исключения действиям. Да, вообще ко всем.

Добавим нового пользователя, для альтернативы root.

sudo adduser имя_пользователя

Если вас не попросили придумать пароль для пользователя, то установите его вручную.

passwd имя_пользователя

Я предполагаю, что мы заблокируем root пользователя, поэтому после этого добавим пользователя в группу sudo:

usermod -aG sudo имя_пользователя

На некоторых ОС эта группа называется wheel.

usermod -aG wheel имя_пользователя

Для каждого пользователя sudo можно задать ограничения: разрешить запускать только определенные команды от имени супер пользователя.

🙅‍♂️ Запрет входа root пользователя

Эффективность: 🛡️ 🛡️ 🛡️ 🛡️ 🛡️

Вы не должны позволять root входить в ваш SSH-сервер. Если злоумышленник получит доступ к root-аккаунту, то он будет иметь полный контроль над сервером. Подключение должно быть разрешено только обычным пользователям. Если им нужно выполнить административную задачу, им также следует использовать sudo.

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

Открываем текстовый файл в любом редакторе:

sudo nano /etc/ssh/sshd_config

Нас интересует параметр PermitRootLogin:

  • Если вы хотите вообще запретить пользователю root вход в систему, установите PermitRootLogin no.
  • Если вы собираетесь разрешить пользователю root входить в систему, но хотите использовать только SSH-ключи, установите PermitRootLogin prohibit-password.

После внесения вышеуказанных изменений сохраните и закройте файл. Затем перезапустите службу SSH, чтобы внесенные изменения вступили в силу.

systemctl restart sshd

Заблокировать пароль root

Эффективность: 🛡️ 🛡️ 🛡️ 🛡️

Я обычно блокирую пароль для пользователя root. Это не позволит обычному пользователю перейти в root пользователя с помощью команды su.

Для этого заходим на сервер под пользователем, обладающим правами sudo. И вводим следующую команду:

sudo passwd -l root

🔐 Используйте SSH ключ вместо пароля

Эффективность: 🛡️ 🛡️ 🛡️ 🛡️ 🛡️ 🛡️

Сервер OpenSSH поддерживает различную аутентификацию. Пароли можно угадывать, взламывать или подбирать методом перебора. Ключи SSH не подвержены таким атакам.

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

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

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

Security root user
Схематичный процесс авторизации по SSH ключу

Создание ssh ключей

И так, генерация ключей ssh выполняется командой:

ssh-keygen

Утилита предложит вам выбрать расположение ключей. По умолчанию ключи располагаются в папке ~/.ssh/. Лучше ничего не менять, чтобы все работало по умолчанию и ключи автоматически подхватывались. Секретный ключ будет называться id_rsa, а публичный id_rsa.pub.

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

Теперь у вас есть открытый и закрытый ключи SSH и вы можете использовать их для проверки подлинности. Дальше нам осталось разместить открытый ключ на удаленном сервере.

Никогда и никому не передавайте свой закрытый ключ.

Загрузка ключа на сервер

Самый простой способ скопировать ключ на удаленный сервер — это использовать утилиту ssh-copy-id. Она входит в пакет программ OpenSSH. Но для работы этого метода вам нужно иметь пароль доступа к серверу по SSH.

ssh-copy-id username@remote_host

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

ssh-copy-id -i /path_to_key username@remote_host

При первом подключении к серверу система может его не распознать, поэтому вам нужно ввести yes. Затем введите ваш пароль пользователя на удаленном сервере. Утилита подключится к удаленному серверу, а затем использует содержимое ключа id_rsa.pub для загрузки его на сервер в файл ~/.ssh/authorizedkeys. Дальше вы можете выполнять аутентификацию с помощью этого ключа.

Если такой способ по какой-либо причине для вас не работает, вы можете скопировать ключ по ssh вручную. Мы создадим каталог ~/.ssh, а затем поместим наш ключ в файл authorized_keys с помощью символа >>, это позволит не перезаписывать существующие ключи:

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Здесь вам тоже нужно набрать yes, если вы подключаетесь к новому серверу, а затем ввести пароль.

Также необходимо убедиться, что имеется возможность входа по ssh ключу. Для этого в файле /etc/ssh/sshd_config должна присутствовать строка PubkeyAuthentication yes.

После этого вы можете использовать созданный ключ для аутентификации на сервере:

ssh username@remote_host

Если вы не захотели создать ssh ключ с доступом по паролю, то вы сразу же будете авторизованы, что очень удобно. Иначе, сначала вам придется ввести фразу-пароль для расшифровки ключа.

🙅‍♂️ Запрет авторизации по паролю

Эффективность: 🛡️ 🛡️ 🛡️ 🛡️ 🛡️

Логическим продолжением использования ключей SSH является полное отключение аутентификации по паролю для всех пользователей.

Прежде чем запрещать вход по паролю, проверьте возможность входа по ssh ключу.

Нам нужно отредактировать ваш файл конфигурации SSH.

sudo nano /etc/ssh/sshd_config

Находим строчку PasswordAuthentication yes и меняем ее на PasswordAuthentication no.

Теперь сохраните файл и перезапустите службу ssh:

sudo service ssh restart

Ограничить доступ пользователей по ssh

Чтобы разрешить доступ по ssh только нужным пользователям, добавьте следующее в sshd_config:

// ... ... ... ... ...

AllowUsers user1, user2

// ... ... ... ... ...

В качестве альтернативы вы можете разрешить всем пользователям входить в систему через SSH, но запретить только нескольким пользователям, с помощью следующей строки в sshd_config:

// ... ... ... ... ...

DenyUsers user1, user2, user3

// ... ... ... ... ...

Запрет X11 Forwarding

Эффективность: 🛡️ 🛡️

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

Стандартная мантра в области кибер-безопасности:

если у вас нет веской причины включить что-то, выключите это

Мы сделаем это, отредактировав файл конфигурации SSH:

sudo nano /etc/ssh/sshd_config

Отредактируйте строчку X11Forwarding yes на X11Forwarding no.

Перезапустите службу SSH:

sudo systemctl restart sshd

Ограничение для попыток ввода пароля

Эффективность: 🛡️ 🛡️

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

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

Нам нужно отредактировать ваш файл конфигурации SSH:

sudo nano /etc/ssh/sshd_config

Прокрутите файл до тех пор, пока не увидите строку, начинающуюся с MaxAuthTries 0. Удалите хеш с начала строки, измените цифру 0 на желаемое. Например 3.

После внесения изменений сохраните файл и перезапустите демон SSH:

sudo systemctl restart sshd

Установите таймаут подключения

Эффективность: 🛡️ 🛡️

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

Есть вероятность, что пользователь покинул свой рабочий стол и оставил компьютер не заблокированным. Любой другой, кто проходит мимо, может сесть и начать пользоваться компьютером. Намного безопаснее установить лимит тайм-аута. Соединение SSH будет прервано, если неактивный период совпадет с лимитом времени. Мы еще раз отредактируем файл конфигурации SSH:

sudo nano /etc/ssh/sshd_config

Устанавливаем параметр ClientAliveInterval 600.

sudo systemctl restart sshd

Отклонять подключение без пароля

Эффективность: 🛡️ 🛡️

Дополнительно:  Как исправить системные ошибки RTKVHD64.sys в Windows 10

Хотя это плохая практика, системный администратор Linux может создать учетную запись пользователя без пароля. Это означает, что запросы на удаленное соединение от этой учетной записи не будут иметь пароля для проверки. Эти соединения будут приняты, но не аутентифицированы.

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

PermitEmptyPasswords no

Бэкапы

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

Заключение

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

Мой коктейль

Это все были разрозненные советы, из которых вы можете собрать свой “рецепт”. Какой рецепт использую я сам?

Чаще всего мой рецепт выглядит так:

  • Смена порта SSH
  • Создание нового sudo пользователя
  • Блокировка входа по паролю для всех пользователей
  • Блокировка входа root на сервер
  • Блокировка пароля root
  • Регулярные бэкапы

Административные средства

Управляя домашним компьютером, пользователь должен выполнять некоторые действия под именем root или получить привилегии root, с помощью программ setuid, например sudo или su. Программы setuid — это программы, работающие с кодом пользователя (UID) владельца программы, а не запускающего их пользователя. В подробном списке файлов эти программы выделяются маленькой буквой s в разделе владельца, как показано ниже:

-rwsr-xr-x    1 root     root        47324 May  1 08:09 /bin/su

Однако системные администраторы организации должны определить, какие административные права должны иметь пользователи на своих компьютерах. С помощью PAM-модуля pam_console.so некоторые действия, обычно разрешённые только пользователю root, например, перезагрузку и извлечение съёмных устройств, можно разрешить первому вошедшему на физическую консоль пользователю (обратитесь к главе Подключаемые модули проверки подлинности (PAM) Справочного руководства Red Hat Enterprise Linux за дополнительными сведениями о модуле pam_console.so). Однако выполнение других важных административных задач, таких как изменение параметров сети, настройка новой мыши или подключение сетевых устройств невозможно без прав администратора. В следствие этого системные администраторы должны решить, какие административные полномочия должны получить пользователи их сети.

Разрешение доступа root

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

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

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

  • Запуск небезопасных служб — Пользователи с правами root могут запускать на своих компьютерах небезопасные службы, например FTP или Telnet, что ставит под угрозу их имена и пароли, передаваемые по сети открытым текстом.

  • Запуск почтовых вложений под именем root — Хотя вирусы для Linux — редкость, но всё же они есть. И они представляют собой угрозу, только если их запускает пользователь root.

Запрещение доступа root

Если по этим или другим причинам администратору не хочется, чтобы пользователи имели права root, пароль root следует хранить в секрете и запретить доступ к первому уровню выполнения или монопольному режиму, защитив загрузчик паролем (подробнее эта тема рассматривается в разделе 4.2.2 Пароли загрузчика системы).

В таблице 4-1 перечислены способы дальнейшей защиты от входа под именем root:

Таблица 4-1. Способы отключения учётной записи root

4.4.2.1. Отключение оболочки root

Чтобы запретить пользователям непосредственный вход под именем root, системный администратор может задать для root оболочку /sbin/nologin в файле /etc/passwd. Это предотвратит доступ к учётной записи root с помощью команд, использующих оболочку, например su и ssh.

4.4.2.2. Запрет входа root

4.4.2.3. Запрет входа root через SSH

Чтобы запретить регистрацию root с использованием протокола SSH, отредактируйте файл настроек демона SSH (/etc/ssh/sshd_config). Измените строку, в которой написано:

4.4.2.4. Отключение root с помощью PAM

PAM-модуль /lib/security/pam_listfile.so даёт большие возможности по отключению учётных записей. Администратор может указать для этого модуля список пользователей, не имеющих разрешения на вход.
Ниже приведён пример использования модуля для демона FTP-сервера vsftpd в файле конфигурации PAM /etc/pam.d/vsftpd (символ \ в конце первой строке не нужен, если всё помещается в одной строке):

auth   required   /lib/security/pam_listfile.so   item=user \
sense=deny file=/etc/vsftpd.ftpusers onerr=succeed

Если администратор желает запретить доступ к нескольким службам, подобную строку можно добавить в конфигурацию PAM для этих служб, например, в /etc/pam.d/pop и /etc/pam.d/imap для почтовых клиентов или /etc/pam.d/ssh для клиентов SSH.

За дополнительной информацией о PAM, обратитесь к главе Подключаемые модули проверки подлинности (PAM) в Справочном руководстве Red Hat Enterprise Linux.

Ограничение доступа root

Вместо того, чтобы полностью закрывать доступ пользователю root, администратор может разрешить доступ только к программам setuid, например, к su или sudo.

4.4.3.1. Команда su

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

Зарегистрировавшись с помощью команды su, пользователь является пользователем root и имеет все права администратора системы. Кроме этого, если пользователь стал root, с помощью команды su он может стать любым другим пользователем системы, не зная его пароля.

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

Проще всего это можно сделать, добавив пользователей в специальную административную группу wheel. Для этого выполните от имени root следующую команду:

usermod -G wheel <username>

Затем перейдите на вкладку Группы и отметьте группу wheel, как показано на рисунке 4-2.

Security root user

Рисунок 4-2. Вкладка Группы

auth  required /lib/security/$ISA/pam_wheel.so use_uid

Сделав, это вы откроете доступ к этой программе только пользователям группы администраторов wheel.

4.4.3.2. Команда sudo

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

Общий формат команды sudo показан ниже:

Команда sudo даёт большую гибкость. Например, только пользователи, перечисленные в файле /etc/sudoers, могут выполнить команду sudo, и эта команда будет выполнена в оболочке пользователя, а не root. Это значит, что оболочка root может быть полностью отключена, как описано в разделе 4.4.2.1 Отключение оболочки root.

Команда sudo также ведёт исчерпывающий аудит. Каждая успешная попытка входа регистрируется в файле /var/log/messages, а выполненная команда, вместе с именем выполняющего её пользователя в файле /var/log/secure.

Другим преимуществом команды sudo является то, что администратор может открыть пользователям доступ только к нужным им командам.

Администраторы, желающие отредактировать файл конфигурации sudo, /etc/sudoers, должны использовать команду visudo.

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

В этом примере пользователь juan может использовать sudo с любого компьютера и выполнить любую команду.

В приведённом ниже примере показано, как можно очень тонко настраивать sudo:

%users  localhost=/sbin/shutdown -h now

В данном примере любой пользователь, работающий на консоли, может выполнить команду /sbin/shutdown -h now.

Подробное описание параметров этого файла можно найти на странице man sudoers.

Хотя системным администраторам *nix систем не стоит беспокоятся о таких вещах, как сетевые или почтовые черви, кража root привилегий представляет реальную угрозу. Уменьшая число знающих пароль root’а, устанавливая в расписании регулярный запрос на смену пароля и разрешая смену только пользователем (команда su) root, администраторы часто думают что они таким образом защитили свои системы. Однако кто-то, кому вы не доверяли управление системой, вполне реально может cкомпрометировать её. В этой статье будут представлены некоторые утилиты для помощи в выявлении и анализе возможных вторжений.

Автор Rhonda Thorne
Перевод Войновича Андрея

Хотя системным администраторам *nix систем не стоит беспокоятся о таких вещах, как сетевые или почтовые черви, кража root привилегий представляет реальную угрозу. Уменьшая число знающих пароль root’а, устанавливая в расписании регулярный запрос на смену пароля и разрешая смену только пользователем (команда su) root, администраторы часто думают что они таким образом защитили свои системы. Однако кто-то, кому вы не доверяли управление системой, вполне реально может cкомпрометировать её. В этой статье будут представлены некоторые утилиты для помощи в выявлении и анализе возможных вторжений.

Если  у вас, как и у меня, на совести не одна система, за которой необходимо присматривать, то вы понимаете что нужно постоянно просматривать логи смен пользователей, файлы истории командной строки и файлы паролей. Мониторинг *nix’овых файлов при помощи автоматизирующих утилит пожалуй самый эффективный способ поддержки безопасности. Если вы используете систему HP 11.0, IDS/9000 систему обнаружения вторжения, то использование ниже описанных утилит скорее всего не даст ожидаемого эффекта.

Мой опыт составляет более шести лет, и следуя «Заповедям сисадмина», я применил всё, чему учился и был уверен, что возможность компрометации была минимальной. Однако, работая на большой проект Y2K, содержащий более 30 приложений, разработку программ и консультации по базам данных, я впервые столкнулся с проблемой в безопасности на уровне доступа root. К счастью, утилиты, обсуждаемые ниже, были под рукой и мне удалось выявить брешь безопасности, вычислить злоумышленника и узнать, какие команды были выполнены в процессе компрометации.

Я получил email, в котором сообщалось, что произошла su (смена пользователя) на root. Пользователь, переключившийся на root, не имел соответствующих прав. Я решил зайти в директорию, где хранился лог всех su на root через командную строку. Теперь я располагал именем пользователя, временем и датой этого события. Далее, я открыл этот файл и увидел, что этот человек выполнил вход в систему как root и запустил команду vi /etc/passwd. Первой моей реакцией было просмотреть файл /etc/passwd, где я нашел дополнительную запись для root, но с другим именем пользователя. Настоящий кошмар сисадмина – система скомпрометирована, и злоумышленник создал бэкдор с правами root.

При последующем просмотре истории командной строки и домашних директорий .sh_history, помимо общей проверки системы, единственным нанесенным ущербом оказался бэкдор и некоторые изменения разрешений в файлах баз данных. Я скопировал файл /etc/passwd, удалил бэкдор из активного файла /etc/passwd, относящийся к нему файл истории и файл sulog.

Закрыв бреши в безопасности, я собрал доказательства и информировал о произошедшем инциденте начальника отдела информационных технологий. При всех доказательствах, начальник не придумал ничего, кроме того, чтобы забыть об этом. Однако он был приятно удивлен быстротой моей реакции и скоростью восстановления системы и закрытия бреши в системе безопасности. Как бы то ни было, я получил кое-какой урок из случившегося и придумал метод оповещения при обнаружении root бэкдоров в файле /etc/passwd.

Эти утилиты не тестировались на линейке продуктов Linux, но должны работать при некоторых ухищрениях со скриптами. Методы были опробованы на платформах IBM AIX, HP-UX и Solaris. Установка:

Дополнительно:  Не работает клавиатура на ноутбуке - что делать, все 10 способов починить

Шаг 1: Принуждение su на root

HP-UX: создайте файл /etc/securetty и добавьте слово CONSOLE. Поменяйте разрешение на файл — chmod 600 /etc/securetty, что приведет к запросу на права root для изменения этого файла.

Solaris: проверьте, что запись CONSOLE=/dev/console в файле /etc/default/login незакомментирована. Разрешения на /etc/default/login должны быть организованы таким образом, чтобы никто не мог изменить этот файл, кроме root, но чтобы права на чтение этого файла были у всех. Можно воспользоваться командой chmod 444 /etc/default/login.

Шаг 2: Перехват индивидуального входа root из истории командной строки

Чтобы поймать злоумышленника, и выяснить какие команды он выполнял, .profile root’а следует проверять на включение создания отдельных логов  командной строки для каждого входа root. Осуществляется это при помощи добавления скрипта и установки оболочки Korn (ksh) в файле /etc/passwd:

Проверьте, что вы закрыли доступ к .profile root’а. Сделать это можно командой chmod 700 .profile, в результате чего никто не сможет даже прочитать .profile. Таким образом истории командной строки каждого пользователя будут хранится отдельно, пока используется оболочка Korn с параметром истории командной строки esc k.Если пользователь или злоумышленник не использует su – когда переключается на root, то эти файлы историй будут храниться в домашней директории злоумышленника (файл .sh_history). Это приводит к тому, что расследование вторжения станет сложным (или вообще невозможным), ведь злоумышленник может почистить свой файл .sh_history. Если это и есть точка перегиба и объяснить пользователям о принуждении su нереально, вы можете сделать выбор между утилитой sudo для постоянных пользователей, которым нужны права root при выполнении некоторых задач, или принуждением su – только для администраторов.

Шаг 3: Оповещание Активности su

#!/usr/bin/ksh
#Name: security.chk
#Written by Rhonda Thorne
#Date 02/98
#Purpose is to report via email any su's to root on a daily basis
 
echo "Here are the su to root list for yesterday" >> /tmp/sec.list
grep `date +%m/%d` /var/adm/sulog|grep -e "-root" >> /tmp/sec.list
mailx -s "su list" sysadmin2 < /tmp/sec.list
rm /tmp/sec.list

Шаг 4: Проверка Файла /etc/password на Root Back Doors

#!/usr/bin/ksh
#Name: passwd.chk
#Written by Rhonda Thorne
#Date 04/98
#This script is to check the /etc/passwd file for duplicate root UID 
#entries (root back doors)
 
count=`grep :0:3:/etc/passwd|wc -l`
if [ $count -gt 1 ]
        then
        echo "Passwd file has a root back door.  INVESTIGATE!" > \
  /tmp/passwd.lst
                echo "Here is the su to root list" >> \
  /tmp/passwd.lst
                grep `date +%m/%d` /var/adm/sulog|grep -e "-root" >> \
  /tmp/passwd.lst
                mailx sysadmin-page < /tmp/passwd.lst
        else
        exit
fi
rm /tmp/passwd.lst

AIX: Поменяйте строку счета в скрипте на :0:0:, которая является UID/GID root’а. При поиске всего лишь :0:, скрипт может оповестить об ошибочных результатах поиска.

HP-UX: Поменяйте строку счета в скрипте на :0:3:, которая является UID/GID root’а, потому что некоторые системы используют значение UID=0 для пользователя system.

Solaris: Поменяйте строку счета в скрипте на :0:1:, которая является UID/GID root’а, потому что некоторые системы используют значение UID=0 для пользователя system. Чтобы заставить работать grep –e, следует иметь /usr/xpg4/bin в корне .profile PATH, или поместить эту запись в ваш скрипт, как показано в шаге 3.

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

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

Оптимизация

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

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

Антивирус

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

Охлаждение

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

Особенности

  • приложение можно скачать и использовать бесплатно;
  • утилита позволяет повысить производительность мобильного устройства и удалить ненужные файлы;
  • доступен встроенный антивирус;
  • есть возможность узнать температуру процессора;
  • приложение совместимо с актуальными версиями Android.

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

Он может быть широко известен специалистам Linux, но я действительно не знаю, почему. Я помню, что всегда работал под управлением root, когда я впервые попробовал Linux несколько лет назад (Redhat и Mandrake) и не помню, чтобы в них возникали проблемы.

На самом деле есть некоторые дистрибутивы с ярко-красным фоном с предупреждающими знаками по всему миру в качестве обоев для пользователя root (SuSe?). Я по-прежнему использую учетную запись «Администратор» для регулярного использования в моей установке Windows и никогда не сталкивался с такими проблемами.

задан
13 September 2017 в 20:04

ответов

Только одно слово: security.

Выполняется как root, потому что:

Причина, по которой вы не могли найти информацию о том, почему это плохо, потому что, ну, есть слишком много данных в Интернете 🙂 и что многие люди, которые долгое время использовали Linux время думаю подобный сделав. Этот способ мышления о корневом аккаунте довольно новый (возможно, десятилетие?), И многие люди все еще раздражаются тем, что нужно использовать sudo. Особенно, если они работают на сервере, что означает, что они вошли с намерением внести изменения в систему. Вероятно, из предыдущих неудачных опытов и стандартов безопасности большинство системных администраторов знают лучше, но им все равно не нравится:).

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

На рабочем столе редко используется учетная запись root. Фактически, Ubuntu отправляется с отключенным доступом root. Все изменения, требующие привилегии суперпользователя, выполняются через sudo и его графические символы gksudo и kdesudo. Учитывая, что легко установить пароль root, однако, почему люди этого не делают?

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

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

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

В многопользовательской системе с неграфическим доступом к оболочке многие из этих причин не применяются. Тем не менее, Ubuntu по-прежнему по умолчанию по умолчанию имеет недоступную учетную запись root. Во-первых, существует реальная разница между получением доступа к учетной записи пользователя (с правами sudo) через отверстие безопасности и получением доступа к root, так как в первом случае сбой других пользователей потребует запуска sudo и будет по-прежнему запрашивать пароль учетной записи в качестве дополнительного шага безопасности. Для другого полезно выполнить многие административные задачи из учетной записи пользователя и только вызвать sudo, когда привилегии суперпользователя абсолютно необходимы. Таким образом, при установке программы из источника рекомендуется создать исходный — запуск configure и make — внутри каталога пользователя и только с помощью sudo make install на последнем шаге. Опять же, это затрудняет съемку себя (и других пользователей многопользовательской системы) в ноге, и это уменьшает вероятность создания скриптов, разрушающих систему. Таким образом, даже на сервере это хороший совет придерживаться администрирования Ubuntu на основе sudo.

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

В противном случае основными причинами не запускать с правами root являются:

Свести к минимуму риск повреждения от несчастных случаев. Если вы запустили rm -fr / home/me/my-subdir в качестве пользователя root, то вы просто резко устранили все важное значение своей машины из-за этого пространства после (первой) косой черты — потому что материал, который идет первым, — это материал, который был добавлен первым — маленькие вещи, такие как ядро, каталог /bin и /etc. Unix расстраивается, если вы их потеряете. Минимизируйте риск повреждения от вредоносных внешних сайтов. Если вы просматриваете root, вы более уязвимы для загрузки вредоносных материалов.

Я использую MacOS X больше, чем Ubuntu, но там root отключен по умолчанию, и он все еще находится на моей машине. Я регулярно обновляю ядро ​​и другие подобные операции — используя sudo (за кулисами). Подобные методы применимы к Linux вообще.

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

есть действительно два взаимосвязанных вопросов.

почему бы не запустить все root, все время?

большинство других ответов покрыть это. Это сводится к:

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

это правда, что даже не делая вещи как root, вы можете причинить вред. Например, вы можете удалить все файлы в свой домашний каталог, который обычно включает в себя всех ваших документов, не из-под root! (Надеюсь, у вас есть резервные копии.)

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

Дополнительно:  Asus keyboard hotkeys windows 10 не работает

почему не дают возможность войти в систему как root?

это не объективно неправильно, чтобы иметь систему, при которой корневой учетной записи, при условии, что

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

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

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

[Ф3][!команда д8], при входе в систему с другой учетной записью. удаленно. В [ф14] счета могут фактически сделать что-нибудь, и он имеет то же имя на практически любой Unix-подобной системе. Войдя в систему как root через [ф15] или других удаленных механизмов, или даже настройка удаленного обслуживания, чтобы разрешить его, вы сделаете ее намного проще для злоумышленников, в том числе автоматизированных скриптов и программ, работающих на бот-сетей, чтобы получить доступ с помощью грубой силы, атака по словарю (и, возможно, некоторых ошибок). Возможно, риск не очень высок, если вы позволите ключ, а не пароль root от входа.

по умолчанию в Ubuntu, ни графический вход под root, ни удаленного входа в систему через SSH не включен, в этих способов. То есть, даже если вы включите корень входа, он до сих пор включен только такими способами, которые достаточно безопасной.

[кадрах, снятых D80] хотя по умолчанию должен защищать тебя, я думаю, это все еще хорошая идея, чтобы проверить вашу конфигурацию SSH, если вы собираетесь включить учетную запись root. И если вы используете другие сервисы, которые предоставляют удаленного входа в систему, такие как FTP, вы должны проверить их. если вы понимаете, как работает Рут и вреде злоупотребление, включение учетной записи root не является очень проблематичным с точки зрения безопасности. Но если вы понимаете, что, вы знаете, что вы почти наверняка не нужно, чтобы включить учетную запись root. [!кадрах, снятых D80]

Корневая учетная запись отключена по умолчанию — это значит, что она существует, но она не используется (кроме режима восстановления). Это означает, что злоумышленник знает вашу учетную запись root, но не мог использовать его, даже если у него / нее был пароль root. Таким образом, злоумышленник должен угадать как имя пользователя с правами администратора, так и пароль пользователя (что намного сложнее, чем просто пытаться выработать пароль root). В XP, если у вас установлена ​​консоль восстановления, любой, кто физический доступ к вашему ящику может загрузиться в него (RC) — пароль не требуется. То же, что и в режиме восстановления в Ubuntu.

В Ubuntu, когда говорят, что root отключен, на самом деле это означает, что учетная запись заблокирована. Учетная запись заблокирована путем изменения пароля до значения, которое не соответствует возможному зашифрованному значению. Это эффективно предотвращает возможность входа в систему с правами root, поскольку невозможно было ввести пароль. Так как еще есть время, когда необходим корневой доступ — ядро ​​Ubuntu было изменено, чтобы разрешить корневой локальный вход только в однопользовательском режиме.

Также см. Эту Корневую учетную запись

Его как вооружение маленького ребенка с AK47, в то время как он может с удовольствием играть с его пейнтбольным оружием. 😉

Я имею в виду, что это неправильно, потому что у вас и ваших приложений будет больше привилегий, чем они нужны, и тогда, когда что-то может и когда-нибудь пойдет не так: (

Когда я начал использовать Linux, который более 10 лет назад, основные дистрибутивы не рекламировали использование не- как и сегодня. Поскольку я был использован для Windows, я также не видел смысла использовать ограниченную учетную запись пользователя. В частности, потому, что мне приходилось очень часто вводить «su», тогда судо не было тогда популярным. 😉 Поэтому я всегда входил в систему как root, потому что у меня было много технического обслуживания, чтобы настроить мою систему. Но предположим, что любая новая установленная система быстро стала нестабильной.

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

Но хорошо: современные дистрибутивы выполняют большинство задач администрирования для вас, поэтому редко вам приходится возиться в кишки вашей Linux-системы с учетной записью root. Ввод пароля время от времени является достаточным, остальные выполняются скриптами дистрибьютора.

Есть много аспектов этого подхода. Некоторые из них: Корень очень мощный. В Unix и Unix-подобных системах привилегии системного администрирования — все или ничего. У пользователя либо есть root-доступ, либо нет, а root-доступ подразумевает полный контроль над машиной. Если рассматриваемая машина используется более чем одним человеком или root имеет доступ к другим системам или пользовательским файлам, более приемлемым является предоставление некоторым пользователям привилегий с частичным root.

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

вот хорошая статья: http: // cf. stanford.edu/policy/root



rm /*

Допустим, вы очистили административную зону. Вы устали от пароля, поэтому вы sudo su. Вы отвлекаетесь только на секунду и забудете cd к /. Тогда вы rm *. Я сделал это. Вы можете вернуть все, но это PITA. О, и он тоже спустился в /media!

Почему у вас нет корневого входа?

Sudo — это альтернатива предоставлению людям пароля root для выполнения обязанностей суперпользователя. При установке по умолчанию Ubuntu лицу, установившему ОС, предоставляется разрешение «sudo» по умолчанию.

Любой, у кого есть разрешение «sudo», может выполнить что-то «как суперпользователь», предварительно ожидая sudo к их команда. Например, чтобы запустить apt-get dist-upgrade в качестве суперпользователя, вы можете использовать:

sudo apt-get dist-upgrade

Преимущества подхода sudo

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

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

С помощью sudo у вас все еще есть возможность открыть постоянный (интерактивный) суперпользователь shell с командой:

sudo su

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

Чтобы уточнить, вы можете, если захотите, предоставить корневому пользователю пароль, позволяющий входить в систему как root, если вы специально хотите сделать это таким образом. Я просто хотел сообщить вам о соглашении Ubuntu о предпочтении sudo и попытаться объяснить некоторые причины, по которым Ubuntu поддерживает этот подход по умолчанию.

Потенциальные преимущества этого в основном связаны с безопасностью:

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

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



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

Я могу добавить, что существует разница между Администратором в Windows и root в Unix. Администратор все еще имеет некоторые ограничения в системах, где root не имеет никаких ограничений. Правильный аналог корня в Windows — это пользователь системы.

Плохая вещь для использования ПК под root / System — это то, что вы можете случайно уничтожить все без предупреждения из ОС.

Если приложения запускаются с правами администратора, нет гарантии, что никто из них не выполнит

rm -rf /

(Это пример команды, которая не должна запускаться.)

Учитывая знающий и внимательный пользователь, я не уверен, что правильный ответ существует. Я не видел этого ответа, поэтому я подумал, что буду звонить.

Мне не нравятся непреднамеренные изменения разрешений на многопользовательские системы, которые мне нужны для chmod позже. Фиксация через chmod после факта гораздо более раздражает, чем необходимость в sudo, но это зависит от того, что я запланировал.

Нет никакой опасности при регистрации в качестве корня, если его использовать осторожно.

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

чтобы создать пользователя в группе sudo с неясным именем, например gamer, и использовать sudo для выполнения административных задач.

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

Причины против использования root:

Возможно случайно уничтожить системные файлы. Может ли заразиться. Не регистрирует действия

Причины использования root:

Мне кажется, что учетная запись без полномочий root может стать жертвой этих причин против использования root, он добавляет подтверждение ваших действий. Я думаю, что, пока вы знаете, что делаете, вы совершенно безопасно используете root. Там я сказал это.


Другие вопросы по тегам:

Похожие вопросы:


Оцените статью
Master Hi-technology
Добавить комментарий