Назад | Перейти на главную страницу

Слишком много процессов, связанных с sshd в Centos 7

Когда я бегу ps aux на моей машине Centos 7 я вижу около 100 записей:

root     19862  0.0  0.0 151692     8 ?        Ss   Oct09   0:00 sshd: unknown [priv]
sshd     19864  0.0  0.0 105068     0 ?        S    Oct09   0:00 sshd: unknown [net]

Я хотел бы спросить, нормально ли это, или моя система подвергается какой-то атаке методом перебора ssh?

Спасибо!

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

Да, очень вероятно, что кто-то пытается пройти аутентификацию на вашем сервере, но не для этого. Если нет, один взгляд на тебя /var/log/auth.log должен указать вам на сервер в вашей сети, на котором запущен устаревший скрипт cron.

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

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

# Disable unused authentication methods
#  !! ONLY DISABLE PASSWORDS IF ALL USERS LOGIN USING KEYS !!
PasswordAuthentication no

# If the above is true, also limit the time users have to present
#  their authentication
# If theres no passwords typed, something <60 seconds is reasonable
#  !! DO NOT SET TOO LOW! USERS MAY STILL NEED TO UNLOCK THEIR KEY/CARD !!
LoginGraceTime 120

# Limit how many times a user can attempt to authenticate
#  !! Users who initially try the wrong key or invalid method will
#  !! first need to configure their ssh client properly
#  !! else they will be locked out if this is too low!
MaxAuthTries 6

# Limit the number of concurrently authenticating users
# start not accepting some connections if there are already 10 clients
# stop accepting any connections if there are already 100 clients
#  !! one may even argue leaving this high is helpful, because
#  !! an attacker needs more resources to prevent legitimate connections
MaxStartups 10:30:100

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

Во-первых, я согласен с тем, что говорит @anx.

Несколько вещей, которые нужно добавить (что я делаю):

  • Для удобства можно использовать fail2ban, который анализирует файлы журналов и блокирует атаки методом грубой силы. Это не повышает безопасность, но снижает шум в ваших журналах.
  • Для повышения безопасности используйте логины на основе ключей.
    • Чтобы вывести это на новый уровень, можно использовать карту openpgp для хранения ключа, так что это уже не файл на диске, который можно украсть. (Карта подписывает запрос, но ключ с карты получить нельзя.)
  • Компромисс, позволяющий не полностью отключить вход на основе пароля, заключается в добавлении 2-й фактор Аутентификация.
    • Можно установить модуль pam аутентификатора Google и приложение для Android. Его можно настроить таким образом, чтобы при входе в систему вам нужно было ввести номер, сгенерированный вашим телефоном (или другим программным обеспечением аппаратного калькулятора), в дополнение к паролю. Это токен, основанный на времени, поэтому, если криптографические проверки пройдут успешно, вы можете войти в систему.
  • Вход на основе ключа и двухфакторная аутентификация могут быть включены одновременно.

Учебник: как установить fail2ban на centos 7