Как я могу мешать ssh ботам пробовать к SSH в как корень

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

При отключении входа в систему как корня в конфигурациях sshd, все еще разрешает ботам соединять, указывать вход в систему как корень и пробовать 3 + времена. Fail2ban затем блокирует их дюйм/с после 5 отказов.

Однако непрерывный объем ботов затем оставляет 8 потоков sshd в памяти в любое время, auth.log на 3 ГБ отказов (30% моего дискового пространства), огромные издержки памяти для fail2ban, чтобы отфильтровать и обработать их всех и медленный ответ, когда мы пытаемся войти в систему, потому что существует 50,000 + IP блоки, в каждое соединение нужно проникнуть сначала, и 20-48MB из памяти, используемой для входа и безопасности, находятся на подкачке из-за системы, требует обрабатывать объем запросов.

Предпочтительное решение: "Когда соединение SSH пытается войти в систему и user=root" затем "sshd разъединение". Любая попытка указать пользователя базируется результаты в отбрасывании соединения.

Это уменьшило бы ненужную обработку для фильтрования всех атак перебором. Я не могу использовать доступ только для ключей, потому что он заставляет вход в систему обходить необходимые 2 факторной аутентификации.

1
задан 8 May 2017 в 23:32

2 ответа

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

1
ответ дан 7 December 2019 в 15:36

Оказывается, что fail2ban может быть изменен, чтобы включить это как нежелательное событие. Измените / добавьте файл конфигурации ssh в filter.d, чтобы включить фильтр для доступа с правами root: https://serverfault.com/questions/340565/how-to-block-all-root-login-attempts-using -denyhosts-and-or-fail2ban

Тогда неудачный бан будет быстрее реагировать на эти входы в систему, но не так быстро, как удаление их на месте (что, как оказывается, потребует изменения кода и перекомпиляция sshd)

Сокращение времени запрета до нескольких часов предотвратит огромный список заблокированных ips, через которые должен будет проходить межсетевой экран, уменьшая накладные расходы и время соединения. Неправильный пароль и время входа в систему как root могут быть настроены отдельно. Таким образом, если у пользователя включен CAPS, это всего лишь несколько минут, но боты с перебором будут заблокированы на 2 часа. (заметил, что время запрета по умолчанию составляет 10 минут, и большинство ботов просто ждут 10:01 минуты и возобновляют свои попытки)

Снижение уровней журнала сокращает все файлы журнала и их накладные расходы памяти. Сокращение времени нахождения fail2ban, уменьшает количество лог-файлов, которые fail2ban хранит в памяти!

Важно иметь правильные настройки, потому что все 3 из этих систем создают любовный треугольник использования памяти! Недостаточная блокировка ботов достаточно скоро приводит к огромным файлам журналов, что означает больше использования памяти rsyslog. Fail2ban хранит эти журналы в памяти для сканирования (# of attacks/second * по findtime). И резервные копии потоков sshd от всех одновременных попыток, которые боты могут делать. Держите bantime слишком коротким, и боты возвращаются, создавая больше потоков sshd. Установите bantime слишком долго, и брандмауэр должен пройти через длинный список разрешений, хранящихся в памяти.

bantime: 5-10 minutes for bad passwords
bantime: 2-6 hours for attempts as root (not days, certainly not 99999999)
log-files: Warn (not info!)
findtime: 5-15 minutes on SSH (log memory usage reduced by quick bans)
maxretry: 2-3
Also config the max attempts permitted in sshd to be 2 because it will dump them to the watched log file much faster

Предстоящие изменения в атаках методом грубой силы (вот почему нам было сложнее) проводить их одновременно. Если вы собираетесь заблокировать их после нескольких попыток, запустите 20-кратные ssh-соединения и попробуйте сразу 20 грубых сил! Все конфиги, приведенные выше, эффективны только против одной IP-атаки. Они менее эффективны, если несколько соединений ssh ​​выполняются одновременно.

Это может быть заблокировано на брандмауэре, предотвращающем более N подключений с данного IP одновременно: https://serverfault.com/questions/275669/ssh-sshd-how-do-i -SET-Max-вход-попытка

0
ответ дан 7 December 2019 в 15:36

Другие вопросы по тегам:

Похожие вопросы: