☰

Советы по преодолению удивительно высокого уровня неудачных попыток входа в систему через sshd в «ботнетах»?

tag-icon • tag-icon linux ssh ddos
Советы по преодолению удивительно высокого уровня неудачных попыток входа в систему через sshd в «ботнетах»?

Я только что настроил сразу два новых Debian 12 VPS.

Один из них работал нормально; к другому у меня, похоже, возникли перебои с подключением. Я даже дошел до того, что написал половину тикета в службу поддержки, думая, что это, должно быть, проблема с подключением в их центре обработки данных, но затем копнул глубже и узнал о функции sshd «MaxStartups»: как только число открытых, но еще не аутентифицированных подключений превышает определенное количество, sshd намеренно начинает сбрасывать дальнейшие подключения, что соответствует тому, что я видел.

На VPS, который работает нормально, логи показывают вредоносную попытку примерно раз в две минуты, чего я и ожидал. На проблемном, кажется, около однойкаждую секундув среднем, поэтому при значении LoginGraceTime по умолчанию в 2 минуты становится совершенно понятно, почему у меня возникли трудности с входом. Я уже сократил это время до 5 секунд, что позволяет держать количество открытых подключений под контролем. (Оба VPS уже настроены на прием только аутентификации с открытым ключом, поэтому в любом случае злонамеренная попытка не может увенчаться успехом.)

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

Я планирую разместить публичный HTTP-сервер на этом VPS, поэтому я также обеспокоен тем, что если он уже стал целью атаки ботнета по SSH, мой HTTP-сервер может оказаться в забвении из-за DDOS-атаки еще до того, как я начну, и/или привлечь внимание кого-то или чего-то, сканирующего его на предмет уязвимостей для эксплуатации. (На другом VPS, где происходит только одна попытка каждые две минуты, я планирую разместить почтовый сервер — не уверен, какой протокол мне следует больше беспокоить!)

  • Какую частоту злонамеренных попыток мне следуетожидатьбыть направленным на случайно выбранный адрес IPv4?
  • Стоит ли мне предпринять какие-либо действия в ответ на это или просто смириться?
    • Спросите у своего провайдера VPS, могут ли они изменить IP-адрес сервера, так как, возможно, мне просто не повезло, и этот сервер стал целью DDOS-атаки на какого-то случайного человека, который затем освободил свой IP-адрес, и он в итоге достался мне?
    • Заблокировать SSH отовсюду, кроме другого моего VPS, через который я могу получить к нему доступ, несмотря на то, что в конечном итоге я все равно буду запускать на нем публичный HTTP-сервер? (кажется, немного бессмысленно отключать SSH-сервер, когда HTTP должен быть открыт, и для меня это было бы умеренно неудобно)
    • Просто отключить сообщения журнала при неудачных попытках? (предполагая, что есть возможность сделать это — я еще не проверял)
    • Есть ли альтернативные пакеты программного обеспечения сервера SSH, которые я могу использовать и которые более оптимизированы для обработки большого количества вредоносных попыток? Например, sshd создает новый процесс для каждого нового соединения перед аутентификацией, что кажется большим количеством ненужных накладных расходов: в идеале он должен потреблять как можно меньше ресурсов, пока аутентификация не будет успешной.
    • ...есть еще предложения?

решение1

Какую частоту вредоносных атак следует ожидать на случайно выбранный адрес IPv4?

Фоновый шум интернета: рутинные, автоматизированные, драгнет-сканирования (а не нацеленные конкретно на ваш адрес IPv4) больших частей интернета, сканирующие открытые хосты и сервисы. Непрерывный поток зондов, легко приводящий к сотням попыток входа/злоупотребления в день только на открытом sshd (хотя цифры могут варьироваться от десятков до (многих) тысяч, при этом определенные диапазоны IP-адресов провайдеров подвергаются нападкам чаще, чем другие) с источниками, варьирующимися от:

  • добросовестные поставщики (которые могут использовать сканеры уязвимостей, чтобы предупреждать/отключать клиентов, если они работают с небезопасными/уязвимыми/скомпрометированными системами)
  • исследовательские проекты (например,shodan.ioи другие) и другие любопытные люди
  • злоумышленники (которые могут использовать ботнеты для выполнения своих зондирований)
  • и т.д. и т.п.

Стоит ли мне предпринять какие-либо действия в ответ на это или просто смириться?

В общем: когда вы открываете сервер и службу для доступа в Интернет, вы должны ожидать подключений и, что самое главное, злоупотреблений (попыток) со стороны всего Интернета.

Если услуга не предназначена как общественная услугазатемэто не должно быть видно всему интернету.
Когда вы можете: лучшей практикой является применение контроля доступа. Это может принимать различные формы, но обычно ограничивает доступ к известным IP-адресам и/или известным диапазонам IP-адресов. Или, в качестве альтернативы, когда вы точно не знаете хорошие диапазоны IP-адресов, блокируйте диапазоны, которые вряд ли когда-либо будут иметь действительные требования доступа.
Хотя привязка IP-адресов (диапазонов) к географическим местоположениям далека от 100% надежности и полной полноты, списки доступа с использованием данных Geo-IP могут быть очень полезны в этом отношении.

Контроль доступа может быть установлен вне хоста, например, с помощью групп безопасности или брандмауэра. Тогда самому серверу не нужно предоставлять никаких ресурсов для их обслуживания.

Часто более гибкими, но также требующими ресурсов от самого хоста, являются средства контроля доступа на основе хоста, такие как брандмауэр на основе хоста (в Linux netfilter/iptables/nftables) или средства контроля доступа в самом приложении. Например, это часто может быть единственным способом установить различные ограничения IP-адресов для разных пользователей.

Когда услуга предназначенадля государственной службы, например, веб-сервер с вашим общедоступным веб-сайтом,обычно вы не применяете контроль доступа, потому что настоящие посетители сайта приветствуются отовсюду.
Часто такие публичные службы вы принимаете подход: разрешить доступ отовсюду, нообнаружить вредоносное поведение и (временно) заблокировать IP-адрес, используемый злоумышленниками. Такой инструмент, какFail2banявляется одним из таких подходов,Системы IDS и IPSдругой.

Пример:Список контроля доступа на странице заказа еды на вынос и системы онлайн-бронирования для местного ресторана, скажем, в Амстердаме, моем родном городе. Вы бы не установили его так, чтобы разрешить доступ только для IP-адресов из Амстердама. Это, вероятно, было бы слишком ограничительным и, например, отпугнуло бы действительных местных посетителей, которые использовали свои мобильные телефоны для доступа к сайту.
Но с другой стороны, блокировка диапазонов IP-адресов, которые, как известно, назначены и используются за пределами Европы и используются, например, в регионах Африки, Азиатско-Тихоокеанского региона, Северной и Южной Америки, должна значительно сократить количество попыток злоупотребления и вряд ли повлияет на количество бронирований / заказов еды на вынос.
Напротив, список контроля доступа для доступа по SSH на том же веб-сервере можно легко ограничить статическими IP-адресами администраторов сайта, шлюзом их офиса и/или, когда у них нет статического IP-адреса или VPN-сервера, диапазонами, используемыми их интернет-провайдерами.

Есть ли альтернативные пакеты программного обеспечения SSH-сервера, которые я могу использовать и которые более оптимизированы для обработки большого количества вредоносных попыток? Например, sshd создает новый процесс для каждого нового соединения перед auth, что кажется большим количеством ненужных накладных расходов:

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

кажется немного бессмысленным отключать SSH-сервер, когда HTTP должен быть открыт

Общий подход к безопасности заключается в следующем:Принцип наименьших привилегий; что в правилах брандмауэра означает:

  • блокировать все по умолчанию
  • разрешать доступ к необходимому только тем, кому это необходимо

Поэтому не бессмысленно разрешать доступ по ssh только с некоторых IP-адресов, а не для всего мира, и разрешить всему миру доступ к портам 80 (чтобы перенаправить просто на https) и 443 — порту https по умолчанию.

решение2

Я ранее не видел атак типа slowloris на ssh. Если посмотреть на документацию, то MaxStartups, похоже, не волнует, исходят ли они от одного и того же клиента (т. е. вы можете способствовать DOS, используя это). Моим первым ответом (в зависимости от характера атак) было бы использование iptables connlimit (ограничение подключений на клиентский IP).

Fail2ban — очевидное решение для большинства атак SSH (я также использовал его для трафика HTTP[S]), но убедитесь, что он настроен на использование ipset.

Изменение IP-адреса вряд ли поможет в долгосрочной перспективе.

Заблокировать SSH отовсюду, кроме другого моего VPS, через который я могу получить к нему доступ

Да, использование jumpbox — довольно распространенная практика. Опять же, это то, что вы можете сделать сами. Просто установите правило брандмауэра по умолчанию для порта 22, а затем добавьте в белый список свой jumpbox(ы). Ssh даже имеет встроенную функциональность, которая делает использование прозрачным, например

ssh -J [email protected] [email protected]

или вы можете установить это в вашем ssh_config и просто ssh targethost.example.com:

Host jumpbox.example.com
   User: jumpuser
   IdentityFile: ~/.ssh/jumpuser.id_rsa

Host targethost.example.com
   User: user
   ProxyCommand: ssh -q -W %h:%p [email protected]:22 
   IdentityFile: ~/.ssh/user.id_rsa

Просто отключить сообщения журнала при неудачных попытках?

Я бы не советовал этого. Можете смело игнорировать их, если вы приняли разумные меры для предотвращения несанкционированного доступа.

Как предполагает pepoluan, вы также можете использовать нестандартный порт и порт-нок (кстати, последнее может бытьреализовано исключительно в iptablesбез необходимости использования knockd)

решение3

Мои предложения:

  1. Измените порт SSH с 22 на другой.
  2. Если боты все еще могут найти ваш порт, установите knockdи настройте свой сервер для реализации функции «перехвата портов».

решение4

Если вы предоставляете доступ к SSH через публичный IP-адрес, рано или поздно он будет просканирован, и злоумышленники попытаются выполнить попытку аутентификации, независимо от провайдера VPS или сети.

Я бы усилил вашу конфигурацию ssh, используя ansible playbook, например такой: https://github.com/dev-sec/ansible-collection-hardening/tree/master/roles/ssh_hardening

Или этот план действий, который укрепляет весь сервер: https://github.com/konstruktoid/ansible-role-hardening

И я бы также рекомендовал fail2ban. Fail2Ban: бан хостов, которые вызывают множественные ошибки аутентификации Fail2Ban сканирует файлы журналов, такие как /var/log/auth.log, и блокирует IP-адреса, которые проводят слишком много неудачных попыток входа. Он делает это, обновляя правила системного брандмауэра, чтобы отклонять новые соединения с этих IP-адресов, в течение настраиваемого периода времени

Или вы можете создать VPN-подключение к сети вашего VPS/создать VPN-сервер на вашем VPS, используя OpenVPN (например), и разместить SSH за VPN, не открывая его из Интернета.

Связанный контент