Я только что проверил свой сервер /var/log/auth.log и обнаружил, что я получаю более 500 уведомлений о неудачных попытках ввода пароля / взлома в день! Мой сайт небольшой, и его URL-адрес неясен. Это нормально? Следует ли мне принимать какие-либо меры?
К сожалению, в сегодняшнем Интернете это вполне нормально. Толпы ботнетов пытаются войти на каждый сервер, который они находят во всех IP-сетях. Как правило, они используют простые словарные атаки на известные учетные записи (например, корневые учетные записи или учетные записи определенных приложений).
Цели атаки не обнаруживаются через записи Google или DNS, но злоумышленники просто проверяют каждый IP-адрес в определенной подсети (например, известных хостинговых компаний с корневыми серверами). Так что не имеет значения, что ваш URL (отсюда и запись DNS) довольно неясен.
Вот почему так важно:
Дополнительно вы можете установить fail2ban который просканирует журнал авторизации, и если он обнаружит определенное количество неудачных попыток входа в систему с IP-адреса, он продолжит добавление этого IP-адреса в /etc/hosts.deny или iptables / netfilter, чтобы заблокировать злоумышленника на несколько минут.
В дополнение к атакам SSH также становится обычным сканирование вашего веб-сервера на предмет уязвимых веб-приложений (некоторые приложения для ведения блогов, CMS, phpmyadmin и т. Д.). Так что убедитесь, что они обновлены и надежно настроены!
Несколько 100 - это нормально ... В прошлом месяце я обнаружил, что на одном из моих серверов было 40 тысяч неудачных попыток. Я решил их построить: карта
Как только я изменил порт ssh и реализовал блокировку портов, число упало до 0 :-)
Я, например, использую «tarpit» в дополнение к разрешению только аутентификации с открытым ключом и запрещению входа в систему с правами root.
В netfilter Eсть recent модуль, который можно использовать с (INPUT цепь):
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, хотя я прекрасно работал без него и только с указанными выше правилами.
РЕДАКТИРОВАТЬ:
При этом можно заблокировать себя, поэтому вы можете добавить что-то вроде следующего, что позволит вам снять бан, постучав по определенному порту:
iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove
Вы могли бы реализовать fail2banили аналогичные методы, такие как привязка SSH к вашему IP. К сожалению, боты все время пытаются использовать брутфорс-доступ, так что это нормально, вам нужно убедиться, что у вас есть хороший пароль.
да. В наши дни это нормально.
По возможности используйте только аутентификацию с открытым ключом для административных целей. Сгенерируйте закрытый ключ на своей рабочей станции:
$ ssh-keygen -t dsa
Скопируйте содержимое ~ / .ssh / id_dsa.pub к вам, серверы ~ / .ssh / authorized_keys (и /root/.ssh/authorized_keys, если вам требуется прямой вход root).
Настройте свои серверы / и т.д. / SSH / sshd_config чтобы принимать только аутентификацию с открытым ключом:
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password
Если у вас слишком много серверов, вы можете использовать Кукольный для запуска открытых ключей и конфигураций к ним.
Смотреть в Denyhosts и fail2ban чтобы заблокировать повторные попытки входа в систему по SSH и увидеть Фырканье если вам требуется полная IDS / IPS.
использовать http://denyhosts.sourceforge.net/
и да, вы должны использовать аутентификацию с открытым ключом и отключить аутентификацию по паролю.
это обычное дело, но это не значит, что вы не должны вести хороший бой. Вот несколько шагов, которые помогут сделать ваш сервер более безопасным.
Вы можете значительно уменьшить это число в общих средах или средах совместного размещения, отключив доступ SSH на любых IP-адресах, связанных с доменными именами. Не включенные в список IP-адреса, не принадлежащие домену, будут получать меньше трафика этого типа, поэтому купите неуказанный IP-адрес и используйте его только для доступа по SSH.
Если вы находитесь в среде, в которой вы можете реализовать IPsec/ VPN в частную сеть в вашей серверной среде, это идеально. Отключите доступ к Интернету по SSH, убедитесь, что у вас есть интегрированное решение для отключения света. Настройте свою VPN и разрешите доступ SSH только из вашей VPN.
Если VLAN не подходит, настройте маршрутизатор или правила брандмауэра, чтобы разрешить SSH-соединения только из известного диапазона IP-адресов.
Если вы выполните эти шаги, вам будет намного легче спать по ночам, зная, что кому-то придется взломать сеть вашей хостинговой компании, чтобы получить доступ к серверу через SSH.
Я бы сказал, что получить только 500 - это немного.
У предыдущего работодателя один из исследователей компьютерной безопасности назвал постоянный поток попыток взлома "интернет-эквивалентом космический шумОн описал это как нормальный, непрерывный поток вредоносного трафика, который ищет системы в Интернете и автоматически использует сценарии для попытки взлома системы. Бот-сети и другие вредоносные системы будут постоянно сканировать и повторно сканировать Интернет на предмет уязвимых систем. очень похоже на SETI.
Попытки механизированы, поэтому цифры кажутся нормальными (да, они высокие по сравнению с некоторыми сайтами и низкие по сравнению с другими). Вам следует предпринять те шаги, которые вам обычно необходимы: вы каждый день считаете свои сайты объектами атаки, даже если вы не обнаруживаете атаки; не обнаружение атаки, не означает, что ее не существует.
В дополнение к использованию механизма автоматической блокировки, такого как fail2ban, у вас есть еще один вариант: фактически связаться с провайдером адреса злоумышленника. Это может показаться совершенно бесполезным, но в случае со сценарием-kiddie их интернет-провайдер более чем готов принять меры.
Чтобы найти адрес злоупотребления, начните с arin.net и найдите IP-адрес с помощью whois. Вы можете быть перенаправлены в другой региональный реестр, но в конечном итоге вы сможете найти ответственного поставщика услуг Интернета для блока IP, который содержит адрес. Найдите адрес abuse @ или просто напишите контактному лицу по техническим вопросам.
Отправьте им вежливое сообщение с соответствующими записями файла журнала (обязательно удалите всю личную информацию) и попросите их принять меры против хоста-нарушителя.
Довольно нормально видеть сотни неудачных соединений SSH.
Если у вас есть возможность, я просто меняю свой SSH-порт на что-то нестандартное. Это не обязательно делает ваш сервер более безопасным, но обязательно очищает журналы (и позволяет увидеть, как кто-то намеренно пытается взломать!)
Да нормально. Что я говорю клиентам в вашей ситуации с небольшими сайтами.
Всегда будьте готовы к взлому.
Создайте копию своего сайта на сервере разработки. Это может быть ваш рабочий стол Windows с использованием XAMPP, который вы можете получить бесплатно.
ВСЕГДА вносите изменения в свой сервер разработки, а затем загружайте их на свой действующий веб-сайт. Если это CMS, такая как Wordpress, разместите свои сообщения на сервере разработки, а затем скопируйте и вставьте их на рабочий сервер.
НИКОГДА не загружайте что-либо с вашего действующего веб-сайта на сервер разработки.
Регулярно проверяйте свои веб-страницы на предмет изменений, которых вы не делали. В частности, скрытые ссылки на лекарства или «улучшающие» продукты. Вы можете найти множество надстроек и программ для браузера, которые сделают это за вас.
Если вы скомпрометированы. Сообщите своему хосту, удалите все, измените все пароли и загрузите чистый сервер разработки на теперь пустой веб-сервер. Работайте со своим хозяином, чтобы предотвратить повторение.
Для небольшого сайта вам не понадобится группа безопасности. Это то, что должен предоставить ваш хост. Если они этого не сделают, тогда получите другой хост, что намного проще сделать, когда у вас есть сервер разработки, чем пытаться переместить рабочий сервер.
Надеюсь это поможет.
Я бы рекомендовал не использовать fail2ban, а запустить SSH (и другие) на нестандартном порту. Я не верю в безопасность посредством неизвестности, но считаю, что это отличный способ уменьшить шум в ваших журналах.
Неудачные попытки входа на нестандартные порты будут редкими и редкими, а также могут указывать на более целенаправленные атаки.
Вы можете даже пойти дальше и установить приманку SSH, например Киппо «впустить» брутфорсеров и посмотреть, что они будут делать, если у них появится такая возможность.
Да, это нормально. Ты можешь :
Fwknop - одна из лучших реализаций блокировки портов, потому что она не является подделкой и фактически аутентифицирует, а не просто авторизует соединение.
Вы можете изменить порт, который использует Openssh, но на самом деле вы не улучшаете безопасность.
Улучшите аутентификацию ssh с помощью Google-аутентификатор или викид
Это защитит атаки на основе паролей и возможность определенного злоумышленника / целевой атаки, скомпрометирующей вашу административную машину и похищающей комбинацию вашего ssh-ключа и пароля.
Просто посмотрите на последние pwn2own comp, чтобы увидеть, насколько легко квалифицированному злоумышленнику взломать ваш полностью исправленный админ-ящик.
В дополнение к другим отличным предложениям, которые вы уже получили, мне также нравится использовать AllowUsers директива, если она подходит для данного сервера. Это позволяет только указанным пользователям входить в систему через SSH, что значительно снижает возможность получения доступа через небезопасно настроенную гостевую / служебную / системную учетную запись.
Пример:
AllowUsers admin jsmith jdoe
Параметр AllowUsers указывает и контролирует, какие пользователи могут получить доступ к службам ssh. Можно указать несколько пользователей, разделенных пробелами.
Другой способ остановить это (поскольку я лично не люблю перемещать порт SSH): решите, можете ли вы перечислить все сети, из которых вы когда-либо захотите войти в систему, а затем разрешите им доступ только к вашему SSH-порту.
Записи в WHOIS местных интернет-провайдеров помогли мне снизить количество атак до 1-2 попыток входа в систему в месяц (тогда это было около 1000 в день). Я обнаружил их, все еще используя запретить.
Я реализовал блокировку портов, и у меня есть несколько пробников в день. У них нет связи, поэтому они уходят. Я регистрирую и сообщаю обо всех доступах к задействованным портам.
Я также запустил fail2ban с Shorewall в качестве брандмауэра, чтобы временно занести в черный список постоянных злоумышленников.
Если вам не нужен доступ в Интернет по SSH, отключите его. Если у вас есть несколько известных адресов, к которым требуется удаленный доступ, ограничьте доступ к этим адресам.
Также может быть полезно ограничение доступа к авторизованным ключам.
К сожалению, это вполне нормально. Вам следует подумать о добавлении чего-то вроде fail2ban в вашу систему, чтобы автоматически обнаруживать и блокировать злоумышленников. Если вы еще этого не сделали, вам также следует рассмотреть возможность использования ssh только с открытыми ключами и не разрешать вход в систему с правами root через ssh. Если для передачи файлов в систему используется ftp, подумайте об использовании scp / sftp.
В наши дни это совершенно нормально.
Вы можете установить ограничение на количество пакетов на брандмауэре для входящих новых подключений через порт SSH,
или установите один из многих парсеров журналов a'la fail2ban или измените порт SSH;).
Последний - самый простой. На сильно нагруженных машинах такие попытки взлома могут серьезно повлиять на всю систему.
-
С Уважением,
Роберт
я использую pam_abl временно занести в черный список брутфорсеры, и он отлично работает. Я думаю, что лучше иметь авторизацию в PAM с использованием собственной базы данных, чем зависеть от hosts.deny или iptables.
Еще один плюс в том, что pam_abl не зависит от сканирования файлов журнала.
Да это нормально.
Я просто изменил порт ssh со стандартного 22. Мой сервер, мои правила :) просто отредактируйте / etc / ssh / sshd_config, измените порт и перезапустите службу. Единственный недостаток заключается в том, что вы должны не забывать добавлять этот порт в конфигурацию для каждого используемого вами ssh-клиента.
Отключите вход в систему с правами root (в каждой системе Linux есть пользователь root, поэтому боты могут легко угадать имя пользователя). После входа в систему как обычный пользователь вы можете переключиться на root с помощью su или sudo.
изменить порт по умолчанию с 22
Разрешить доступ по ssh только с известных IP
Используйте надежный буквенно-цифровой пароль для пользователя с доступом по ssh