Множество попыток взлома в день — как с этим бороться?

Я только что проверил журнал /var/log/auth.log моего сервера и обнаружил, что я получаю более 500 уведомлений о неудачных попытках ввода пароля/взлома в день! Это нормально? Что мне предпринять?

Ответ 1

В современном интернете это, к сожалению, вполне нормальное явление. Полчища ботнетов пытаются войти на каждый сервер, который они находят в IP-сетях. Как правило, они используют простые словарные атаки на известные учетные записи (например, root или учетные записи некоторых приложений). Цели атаки не определяются через Google или DNS, злоумышленники просто пробуют каждый IP-адрес в определенной подсети (например, известных хостинг-компаний с корневыми серверами). 

Вот почему так важно:

1. запретить root-логин в SSH (howto);

2. использовать надежные пароли везде (также в ваших веб-приложениях);

3. для SSH по возможности использовать аутентификацию с открытым ключом и полностью отключить аутентификацию по паролю (howto).

Кроме того, вы можете установить программу fail2ban, которая будет сканировать журнал authlog и, если обнаружит определенное количество неудачных попыток входа с определенного IP, добавит этот IP в /etc/hosts.deny или iptables/netfilter, чтобы заблокировать атакующего на несколько минут.

В дополнение к SSH-атакам также становится распространенным сканирование вашего веб-сервера на наличие уязвимых веб-приложений (некоторые приложения для ведения блогов, CMS, phpmyadmin и т. д.). Поэтому убедитесь, что они тоже обновлены и безопасно настроены!

Ответ 2

Я, например, использую «tarpit» в дополнение к разрешению только аутентификации с открытым ключом и запрещению входа root. В netfilter есть модуль, который вы можете использовать с (INPUT chain):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP

iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

Это приводит к тому, что каждая попытка подключения к порту 22 перечисляется модулем recent с IP и некоторыми другими данными под именем «tarpit» (если вам интересно, посмотрите в /proc/net/xt_recent/tarpit). Очевидно, что вы можете использовать другие имена.

Чтобы перечислить или исключить IP из списка, используйте:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit

echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Это ограничивает количество попыток до 5 за 300 секунд. Обратите внимание, что пользователей с существующим соединением это ограничение не беспокоит, так как они уже имеют установленное соединение и им разрешено создавать больше (даже сверх ограничения скорости).

Настройте правила по своему вкусу, но убедитесь, что они добавлены в таком порядке (т. е. при добавлении используйте их в этом порядке, при вставке — в обратном).

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

Вы все еще можете комбинировать это с fail2ban, хотя я прекрасно работал без него и только с вышеуказанными правилами.

Ответ 3

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

Избегайте IP-адресов, связанных с DNS

Вы можете значительно уменьшить это число в средах с общим доступом или colocation, отключив доступ к SSH на любых IP-адресах, связанных с доменными именами. IP-адреса, не связанные с доменными именами, которые будут получать меньше трафика такого типа, поэтому купите IP-адрес без списка и используйте его только для SSH-доступа.

Используйте VPN для всего SSH-доступа

Если вы находитесь в среде, в которой вы можете реализовать IPsec/VPN для частной сети внутри вашей серверной среды, это идеальный вариант. Отключите весь SSH-доступ в интернет, убедитесь, что у вас есть интегрированное решение для отключения доступа. Настройте VPN и разрешите SSH доступ только из VPN.

Внедрите правила IP-адресов для доступа к SSH

Если VLAN не подходит, настройте маршрутизатор или правила брандмауэра так, чтобы разрешить SSH-соединения только из известного диапазона IP-адресов.

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

Ответ 4

В дополнение к использованию автоматического механизма блокировки, такого как fail2ban, у вас есть еще один вариант — связаться с ISP злоумышленника. Это может показаться совершенно бесполезным, но в случае со скрипт-кидди их ISP более чем готов принять меры против них.

Чтобы найти адрес злоумышленника, начните с arin.net и найдите IP-адрес с помощью whois. Вас могут перенаправить в другой региональный реестр, но в итоге вы сможете найти провайдера, ответственного за IP-блок, в котором находится адрес. Найдите адрес abuse@ или просто отправьте письмо техническому контакту.

Отправьте им вежливое сообщение с соответствующими записями в журнале (убедитесь, что удалили любую частную информацию) и попросите их принять меры против хостера-нарушителя.

Ответ 5

Да, это нормально. Что я говорю клиентам в вашей ситуации с небольшими сайтами.

Всегда будьте готовы к взлому. Имейте копию вашего сайта на рабочем сервере. Это может быть ваш рабочий стол Windows с использованием XAMPP, который вы можете получить бесплатно. ВСЕГДА вносите изменения на своем сервере, а затем загружайте их на свой рабочий сайт. Если это CMS, например, Wordpress, создавайте посты на тестовом сервере, а затем копируйте и вставляйте их на рабочий сервер.

НИКОГДА не загружайте ничего с рабочего сайта на рабочий сервер.

Регулярно проверяйте свои веб-страницы на предмет изменений, которые вы не делали. В частности скрытые ссылки или спам. Вы можете найти множество надстроек для браузеров и программ, которые сделают это за вас.

Если вас взломали. Сообщите своему хостеру, удалите все, смените все пароли и загрузите свой чистый рабочий сервер на пустой веб-сервер. Взаимодействуйте с вашим хостером, чтобы предотвратить повторение.

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

Ответ 6

Да, это нормально. Вы можете:

1. Уменьшить возможность атаки с помощью fwknop

Fwknop — одна из лучших реализаций нок порта, потому что она не подделывается и действительно аутентифицирует, а не просто авторизует соединение.

Вы можете изменить порт, который использует Openssh, но это не улучшит безопасность.

Усильте аутентификацию ssh с помощью Google-аутентификатора или wikid.

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

Просто посмотрите на последний pwn2own comp, чтобы увидеть, как легко опытному злоумышленнику скомпрометировать ваш полностью пропатченный административный компьютер.