Как я отключаю корневой вход в систему в Ubuntu?

это - также хорошая идея о debian и debian-производных как человечность, чтобы отредактировать/etc/default/rcS на удаленных серверах и установить "FSCKFIX=yes"

это добавляет "-y" ко времени начальной загрузки fsck, таким образом, он не рискует удаленным сервером, застревающим, ожидая кого-то, чтобы войти в систему в консоли и выполнить fsck.

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

и если Вы не можете использовать раздел подкачки, можно настроить запись личинки для начальной загрузки в живое изображение CD (использующий ядро и initrd из ISO)..., но необходимо будет изменить initrd файловую систему, чтобы иметь корректный IP-адрес и т.д. и удостовериться, что sshd работает. clonezilla, gparted или systemrescuecd сделали бы хорошие живые системы для использования в качестве основы для этого. Ваш раздел/каталог начальной загрузки / должен быть достаточно большим для содержания этих файлов.

27
задан 4 September 2010 в 17:37
7 ответов

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

Отключите корень ssh доступ путем редактирования /etc/ssh/sshd_config содержать:

PermitRootLogin no

Игра с /etc/shadow, chsh -s /bin/false root все могут быть отменены с простым загрузочным CD/картой флэш-памяти.

Обновите на свой комментарий:

Из help.ubuntu.com: "По умолчанию корневой пароль учетной записи заблокирован в Ubuntu". Посмотрите раздел "Re-disabling your root account" конкретно. Для сброса состояния учетной записи корня, к значению по умолчанию установки, используйте следующую команду:

sudo usermod -p '!' root
33
ответ дан 28 November 2019 в 20:04
  • 1
    Никакая система не является защищенной, когда у взломщика есть физический доступ к той системе. Когда можно отредактировать/etc/shadow, что мешает Вам редактировать/etc/ssh/sshd_config? полукровка –  Sven♦ 4 September 2010 в 17:33
  • 2
    @SvenW: Точно. Именно поэтому я обсуждаю полноценность, мудрую безопасностью, ровного того, чтобы потрудиться "отключить" корень. Ограничьте доступ корня, да. Отключите учетную запись, нет. –  jscott 4 September 2010 в 17:38

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

PermitRootLogin no

и перезапуск ssh сервис

sudo service ssh restart

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

21
ответ дан 28 November 2019 в 20:04
  • 1
    Извините, я должен был сказать, это для локальных логинов. Я обновил вопрос. –  Ben Hymers 4 September 2010 в 17:38

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

Это должно препятствовать тому, чтобы кто-то тестировал груду имен пользователей, попытался узнать, которые допустимы в Вашей системе. Однако с точки зрения безопасности, если Вы отключили корень по SSH, я также настроил программу обнаружения "в лоб" (как fail2ban) и установил его так, чтобы, если кто-то даже пытается войти в систему как корень, он заблокировал их от попытки любых дополнительных нападений.

4
ответ дан 28 November 2019 в 20:04
  • 1
    Хороший ответ, Спасибо! у меня уже есть fail2ban, настроенный, я настрою его для блокирования на первой попытке входа в систему как корень хотя, хороший совет. –  Ben Hymers 6 September 2010 в 11:44

Замена зашифрованного пароля с * в/etc/shadow (второе поле, после первого ':') лучший способ, по моему скромному мнению. Кроме того, деактивируйте корневой вход в систему для ssh (этот способ, которым просто невозможно войти в систему через ssh как корень), и, возможно, ограничьте ssh для сертификации логинов, который намного более безопасен, чем основанные на пароле логины.

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

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

2
ответ дан 28 November 2019 в 20:04
  • 1
    у меня есть чувство '*', совпадает с'!', согласно принятому ответу, таким образом, я проголосую за этот ответ также. –  Ben Hymers 4 September 2010 в 19:00

Если Вы хотите отключить локальный корневой вход в систему, можно попытаться изменить/etc/passwd и заменить/bin/bash/bin/false. ОДНАКО, так как я не протестировал его, я сказал бы, оставляют корневую сессию открытой на стороне, тестируют его, и если существует какой-либо странный побочный эффект, возвратите его.

0
ответ дан 28 November 2019 в 20:04

Для первого совпадения есть очень веские причины производительности. Первое совпадение позволяет останавливать сканирование при совпадении пакета. По этой причине обычно устанавливаются УСТАНОВЛЕННЫЕ, СВЯЗАННЫЕ правила в верхней части их цепочек. Без первого правила сопоставления каждый пакет должен был бы сопоставляться с каждым правилом в каждой применимой цепочке, что становилось все дороже по мере роста набора правил. Более загруженные брандмауэры, вероятно, будут иметь большие наборы правил и могут иметь проблемы с производительностью с последним совпадением.

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

Можно добавить правило после предыдущего правила, но оно будет отображаться перед правилом, добавленным ранее. Для этого используется iptables -I для добавления правила, а не iptables -A . Использование индекса правила, которое вы хотите обойти, сохранит правила вместе в цепочке. Этот подход может дать вам то, что вам нужно, если вы изменяете действующий набор правил. Я бы посоветовал упорядочить ваши правила так, чтобы они работали с первым совпадением.

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

  • УСТАНОВЛЕННЫЙ, СВЯЗАННЫЙ (выполняется автоматически ShoreWall)
  • Протоколы, чувствительные к задержке (NTP и т. Д.).
  • Требуемые протоколы (DNS и т. Д.).
  • Широко используемые протоколы (HTTP, SMTP, IMAP и т. Д.) .
  • Редко используемые протоколы.

Встроенные цепочки имеют ПОЛИТИКУ, которая может быть ACCEPT, REJECT или DROP. Это применимо, если правила не совпадают. звучит хорошо. Как вы это делаете?

Джим (младший)

0
ответ дан 28 November 2019 в 20:04

JR et al,

Ваши AllowUsers привели меня к этому https://help.ubuntu.com/community/SSH/OpenSSH/Configuring

sudo vi / etc / ssh / sshd_config

PermitRootLogin yes (изменено на no)

(добавить строку в конец файла) DenyUsers user1 user2

сохранить и выйти, а затем

sudo service ssh restart

Моя проблема решена. Спасибо всем.

1
ответ дан 28 November 2019 в 20:04

Теги

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