Слишком много процессов, связанных с 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. Его можно настроить таким образом, чтобы при входе в систему вам нужно было ввести номер, сгенерированный вашим телефоном (или другим программным обеспечением или программным калькулятором), в дополнение к паролю. Это токен, основанный на времени, поэтому, если криптографические проверки пройдут успешно, он предоставляет вам вход в систему.
- Вход в систему на основе ключа и двухфакторная аутентификация могут быть включены одновременно.