Пароль такого уровня не поддаётся ни запоминанию, ни вводу с первого раза. Последовав вашему совету, пользователь проклянёт вас на третий раз.
Если у вас множество серверов, окружений, вы не будете хранить все пароли в голове. Для это используют специальные программы (password manager'ы), например, KeePass.
Немного не понятен следующий момент. ЗАЧЕМ оставлять вход по паролю через SSH?
В статье я как раз рекомендую использовать SSH-ключи вместо паролей - это описано в пункте 2 (SSH-ключи вместо паролей)
Скрытый текст
Уровень "Стандарт" (рекомендуется):
Аутентификация только по SSH-ключам
2. SSH-ключи вместо паролей
Это отключит вход по паролю и включит аутентификацию только по ключам.
по-моему решает вообще все проблемы, нет? Нет необходимости изобретать логины, смены портов, файлбан и прочее? Как только отключается парольный вход, количво атак равняется 0.
Это не так. Даже при отключённой аутентификации по паролю боты и сканеры всё равно будут продолжать "стучаться" в порт SSH. Каждое такое подключение требует обработки TCP-handshake, key exchange, что расходует CPU и память. Как пример эффективности, смена порта снизила число атак с 58 000 до 2 700.
Стоит также помнить о уязвимостях в сервисах. Например, уязвимость в том же OpenSSH CVE-2024-6387 (июль 2024), которая позволяла без какой-либо аутентификации (ключей, паролей) исполнять произвольный код с привилегиями root на атакуемом сервере.
Необходим комплексный подход к защите. Поэтому в конце статьи я пишу: "Принцип многоуровневой защиты - не полагайтесь на один метод"
Как сделать систему более уязвимой, нагородить огород. Вместо использовать ключи.
Это справедливо для избыточной сложности. Но базовый набор (ключи + смена порта + Fail2Ban + обновления) - это не rocket science, это 30 минут настройки один раз. Альтернатива "только ключи и всё" работает до первого инцидента.
Ситуация неприятная. Поэтому важно ставить надёжные и разные пароли для каждого пользователя базы данных, а также удалить анонимных пользователей и периодически делать резервные копии, чтобы избежать потери данных в подобных случаях. Ещё можно рассмотреть смену стандартного порта на другой.
Не все интернет-провайдеры предоставляют статический IP-адрес, некоторые делают это только как платную дополнительную услугу. Также, если подключаться к серверу с разных устройств или сетей, такой способ будет неудобен.
Количество попыток входа помогает понять, насколько сервер подвержен атакам. Если их становится слишком много, это создаёт нагрузку, забивает логи и может привести к снижению производительности. Т.е. это сигнал о том, что стоит принять дополнительные меры защиты.
Выполнил шаги из инструкции, указанная ошибка не воспроизводится. По всей видимости, группа Full не определена в основном конфиге. Убедитесь, что в файле /etc/aide/aide.conf в самом начале присутствуют следующие строки:
# Определение наборов правил
Normal = R+p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
Full = R+a+c+m+u+g+s+sha512
# Подключение нашего конфига
@@include /etc/aide/aide.conf.d/system_paths.conf
SSH-ключи надёжны и их нужно использовать, но полностью полагаться только на них - плохая идея. Возможно, вы ещё не сталкивались с крупными атаками: множественные автоматические переборы могут сильно нагружать сервер. В опыте работы в облачном хостинге я не раз видел, как такие атаки приводили к высокой загрузке CPU и даже "ложили" серверы. Именно поэтому я пишу в конце статьи: "Принцип многоуровневой защиты — не полагайтесь на один метод".
Отлично) SSH-ключи и ufw уже обеспечивают хорошую защиту. Можно ещё сменить порт SSH на нестандартный. На практике это значительно сокращает количество автоматических атак.
Вы не совсем правы) Не зря я написал "при большом количестве "висящих" соединений".
Поясню: В Linux каждое TCP-соединение - это сокет, который занимает дескриптор файла. По умолчанию у процесса, например, у демонов вроде sshd или httpd, есть лимит на число открытых дескрипторов, обычно от 1024 до 4096. TARPIT же не рвёт соединение, а держит его открытым. Если атакующий, например, ботнет, инициирует тысячи соединений в секунду, что в текущих реалиях легко достижимо, то сервер быстро исчерпает все доступные дескрипторы и перестаёт принимать новые соединения, включая легитимные. Это приведёт к DoS на самом сервере, где TARPIT, предназначенный для защиты, сам станет уязвимостью. Также каждое "залипшее" соединение ест память под TCP-буферы.
Интересная альтернатива fail2ban. Ещё стоит учитывать, что такой вариант не пишет логи, модуль recent работает на уровне ядра и просто хранит список IP в памяти. Если нужны записи о блокировках, можно добавить правило с -j LOG или использовать fail2ban.
Не совсем понял ваш комментарий. Если вы про аутентификацию по логину и паролю, то большинство пользователей до сих пор используют именно её. Часто это стандартный пароль, сгенерированный автоматически. Хотя вход по SSH-ключам более надёжный вариант.
Парольная фраза хороший вариант.
Если у вас множество серверов, окружений, вы не будете хранить все пароли в голове. Для это используют специальные программы (password manager'ы), например, KeePass.
В статье я как раз рекомендую использовать SSH-ключи вместо паролей - это описано в пункте 2 (SSH-ключи вместо паролей)
Скрытый текст
Это не так. Даже при отключённой аутентификации по паролю боты и сканеры всё равно будут продолжать "стучаться" в порт SSH. Каждое такое подключение требует обработки TCP-handshake, key exchange, что расходует CPU и память.
Как пример эффективности, смена порта снизила число атак с 58 000 до 2 700.
Стоит также помнить о уязвимостях в сервисах. Например, уязвимость в том же OpenSSH CVE-2024-6387 (июль 2024), которая позволяла без какой-либо аутентификации (ключей, паролей) исполнять произвольный код с привилегиями root на атакуемом сервере.
Необходим комплексный подход к защите. Поэтому в конце статьи я пишу: "Принцип многоуровневой защиты - не полагайтесь на один метод"
Это справедливо для избыточной сложности. Но базовый набор (ключи + смена порта + Fail2Ban + обновления) - это не rocket science, это 30 минут настройки один раз.
Альтернатива "только ключи и всё" работает до первого инцидента.
Ситуация неприятная. Поэтому важно ставить надёжные и разные пароли для каждого пользователя базы данных, а также удалить анонимных пользователей и периодически делать резервные копии, чтобы избежать потери данных в подобных случаях. Ещё можно рассмотреть смену стандартного порта на другой.
Не все интернет-провайдеры предоставляют статический IP-адрес, некоторые делают это только как платную дополнительную услугу. Также, если подключаться к серверу с разных устройств или сетей, такой способ будет неудобен.
Эта статья в первую очередь про методы защиты. При желании вы можете собрать логи, доказательства и отправить их на abuse-ящик провайдера.
Количество попыток входа помогает понять, насколько сервер подвержен атакам. Если их становится слишком много, это создаёт нагрузку, забивает логи и может привести к снижению производительности. Т.е. это сигнал о том, что стоит принять дополнительные меры защиты.
Выполнил шаги из инструкции, указанная ошибка не воспроизводится.
По всей видимости, группа Full не определена в основном конфиге.
Убедитесь, что в файле /etc/aide/aide.conf в самом начале присутствуют следующие строки:
SSH-ключи надёжны и их нужно использовать, но полностью полагаться только на них - плохая идея. Возможно, вы ещё не сталкивались с крупными атаками: множественные автоматические переборы могут сильно нагружать сервер.
В опыте работы в облачном хостинге я не раз видел, как такие атаки приводили к высокой загрузке CPU и даже "ложили" серверы. Именно поэтому я пишу в конце статьи: "Принцип многоуровневой защиты — не полагайтесь на один метод".
Отлично) SSH-ключи и ufw уже обеспечивают хорошую защиту.
Можно ещё сменить порт SSH на нестандартный. На практике это значительно сокращает количество автоматических атак.
Проверил логи 4-х серверов: максимальное количество неудачных попыток для webmaster - 18.
Топ пользователей из /var/log/auth.log одного сервера:
На светлой)
Боты не дремлят! Уже применили что-нибудь из статьи?
Вы не совсем правы) Не зря я написал "при большом количестве "висящих" соединений".
Поясню:
В Linux каждое TCP-соединение - это сокет, который занимает дескриптор файла. По умолчанию у процесса, например, у демонов вроде sshd или httpd, есть лимит на число открытых дескрипторов, обычно от 1024 до 4096. TARPIT же не рвёт соединение, а держит его открытым. Если атакующий, например, ботнет, инициирует тысячи соединений в секунду, что в текущих реалиях легко достижимо, то сервер быстро исчерпает все доступные дескрипторы и перестаёт принимать новые соединения, включая легитимные. Это приведёт к DoS на самом сервере, где TARPIT, предназначенный для защиты, сам станет уязвимостью. Также каждое "залипшее" соединение ест память под TCP-буферы.
Ошибка в отсутствии файла. Если бы файл существовал, но у вас не было прав на него, ls выдал бы сообщение следующего содержания:
Интересная альтернатива fail2ban. Ещё стоит учитывать, что такой вариант не пишет логи, модуль recent работает на уровне ядра и просто хранит список IP в памяти.
Если нужны записи о блокировках, можно добавить правило с -j LOG или использовать fail2ban.
Пример правил:
Хорошая шутка)
Да, TARPIT делал брутфорс менее удобным и ресурсоёмким, но при большом количестве "висящих" соединений есть риск исчерпать ресурсы сервера.
Не совсем понял ваш комментарий. Если вы про аутентификацию по логину и паролю, то большинство пользователей до сих пор используют именно её. Часто это стандартный пароль, сгенерированный автоматически. Хотя вход по SSH-ключам более надёжный вариант.
Возможно, у вас другой дистрибутив.
Например, на CentOS / Fedora логи находятся в /var/log/secure .
Разные семейства Linux используют разные настройки логирования: Debian-подобные системы пишут в auth.log, а Red Hat в secure.
Также посмотреть логи SSH можно через команду:
Если же нужны неудачные попытки входа, можно отфильтровать вывод, например:
sudo journalctl -u sshd | grep "Failed password"Рад, что совет из статьи вам помог!