SSH: su root или sudo?

Пока что я отключил PermitRootLogin на SSH и переключил порт.

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

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

Это личное предпочтение; есть веские причины для выбора любого подхода.

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

Тем не менее, переключение на root и использование sudo описанным вами способом в значительной степени взаимозаменяемы, за исключением нескольких вещей:

• Sudo может регистрировать каждую команду, выполняемую через него. При использовании su вы должны полагаться на историю оболочки root для ведения журнала. (Злоумышленник может легко обойти это, например, просто выполнив sudo su)

• С sudo вам обычно нужен пароль пользователя, с su вам нужен root.

• С sudo проще чередовать привилегированные и непривилегированные команды.

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

• По умолчанию sudo ограничено определенными учетными записями.

  Для su аналогичного можно добиться, используя pam_wheel.so чтобы ограничить su-to-root членами определенной группы. (addgroup --system wheel, adduser YOU wheelраскомментируйте строку pam_wheel в /etc/pam.d/su)

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

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

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

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

Несколько дополнительных советов:

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

  Мне нравится делать это addgroup --system allowssh, а затем в /etc/ssh/sshd_config установка PubkeyAuthentication noи добавив Match Group allowssh\n PubkeyAuthentication yes строфа.

  Я уверен, что это можно сделать и через PAM, используя что-то вроде auth required pam_succeed_if.so quiet_success user ingroup allowssh в /etc/pam.d/sshd.

• Рассмотрите возможность установки logchecker, который сообщает об аномалиях. Чтобы сократить объем писем, вы можете подумать о том, чтобы успешный отправленные по почте попытки входа в систему, а не неудачные.

Мои мысли:

• Устанавливать PasswordAuthentication и PermitRootLogin к no
• При желании введите парольную фразу для своих ключей SSH (хотя это невозможно сделать)
• Используйте MFA, поскольку ответ Тима предлагает еще больше ограничить доступ SSH (лично я бы сделал это через Плагин Google Authenticator от PAM)
• Не включайте sudo без пароля и убедитесь, что для ваших пользователей установлены надежные пароли.
• Менять порт для SSH на самом деле не нужно, любой специальный сканер портов найдет ваш открытый порт.
• Использовать Fail2Ban для защиты от SSH-атак грубой силы
• Отключите переадресацию портов, установив AllowTcpForwarding no
• Что касается iptables, используйте правило «запретить по умолчанию» для систематического удаления всего, что не находится в вашем белом списке портов.
• Если вы суперпараноик, используйте iptables, чтобы ограничить доступ SSH к заведомо исправному IP-адресу (обратите внимание, что это не очень хорошая идея, если вы входите из дома или с IP-адреса, который может измениться).

Что мы делаем (компания ops), так это отключаем вход по паролю и разрешаем только ключи. Использовать криптостик (новое имя, NitroKey) или просто интеллектуальная карточка, но это означает, что вам также понадобится читатель. Таким образом, у вас будет двухфакторная аутентификация, что-то, что у вас есть (флешка или карта), и что-то, что вы знаете (пароль для sudo).

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