Логика отключения рут-логина
Пользователь Ubuntu 14.04 VPS здесь.
Мой VPS был взломан дважды. И третья версия вышла. Скрещенные пальцы.
Ошибка, которую я сделал в первых двух, состояла в том, что у меня был включен root + пароль. С тех пор я узнал, что есть боты, которые продолжают пробовать пароли, пока не получат доступ. Так что на этот раз я собираюсь проложить маршрут по закрытому ключу SSH без пароля
Что я узнал в процессе: по умолчанию Ubuntu Linux никоим образом не ограничивает попытки ввода пароля. Вы можете продолжать пробовать разные пароли навсегда. ~ Дрожь ~.
У меня есть несколько вопросов о логике отключения root-входа:
Может ли пользователь без полномочий root использовать "su", чтобы стать пользователем root? Если да, то сколько попыток ввода пароля разрешено (т.е. это тоже ситуация, когда по умолчанию нет ограничений на попытки ввода пароля?).
Время от времени по-прежнему потребуется доступ типа "root" к серверу, например, чтобы дать новым пользователям привилегии "sudo" и т. Д. Предположительно, у пользователя будет учетная запись без полномочий root с привилегиями "sudo", чтобы можно было иметь такой "рутинный" доступ. Почему это не такая большая угроза безопасности, как включение root-входа?
Опытные администраторы Linux-сервера обычно настраивают пользователя без полномочий root таким образом, чтобы ему требовался закрытый ключ SSH И пароль? Мне кажется, это самый безопасный вариант.
Обновление: я понимаю, что имя пользователя root является проблемой здесь. Но с учетом бесконечных бесплатных попыток взломать любую комбинацию имени пользователя и пароля - это вопрос времени.
1 ответ
Вопрос: Будет ли возможность для пользователя без полномочий root использовать "su", чтобы стать пользователем root? Если да, то сколько попыток ввода пароля разрешено (т.е. это тоже ситуация, когда по умолчанию нет ограничений на попытки ввода пароля?).
Ответ: Да, по-прежнему существует неограниченное количество попыток подключения с использованием "sudo" и "su" по умолчанию, но вы можете ограничить его с помощью pam.d. Причина, по которой эта проблема устранена, заключается в задержках, необходимых для программного запуска команд su и sudo. Они предназначены для замедления атаки, поэтому "вечность" ОЧЕНЬ долгое время, и боты действительно не могут проводить словарные атаки, которые стоят со скоростью 1 за X секунд, где, как и с ssh, кто-то может попробовать пароли с невероятно высокой скоростью.,
ВОПРОС: Время от времени все равно потребуется "root-подобный" доступ к серверу, например, чтобы дать новым пользователям привилегии "sudo" и т. Д. Предположительно, у пользователя будет учетная запись без полномочий root с привилегиями "sudo", чтобы можно иметь такой "рутинный" доступ. Почему это не такая большая угроза безопасности, как включение root-входа?
ОТВЕТ: sudo позволяет пользователям выполнять КОНКРЕТНЫЕ команды как другой пользователь. Вы можете заблокировать sudo, чтобы пользователи могли выполнять только определенные действия. При полном root-доступе пользователь не ограничен и не отслеживается. С помощью sudo все действия также отслеживаются, если, конечно, вы не предоставили им sudo для bash (фактически войдя в систему как root через sudo).
ВОПРОС: Опытные администраторы Linux-сервера обычно настраивают пользователя без полномочий root таким образом, чтобы ему требовался закрытый ключ SSH И пароль? Мне кажется, это самый безопасный вариант.
ОТВЕТ. Как правило, root никогда не имеет права входить в систему напрямую. Для root не настроена эквивалентность ключей ssh. Все контролируется через sudo, так что вы можете отслеживать, кто вошел в систему и что сделал, когда. Обычно крупные компании могут войти в систему как root через физический консольный терминал или виртуальную консоль tty.
Хотя вы не спрашивали об этом, вы можете немного ограничить ssh следующим образом:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP