Действительно ли нормально получить сотни попыток взлома в день?

Да это нормально.

Я просто изменил ssh порт далеко от стандартных 22. Мой сервер, мои правила :) просто редактирует/etc/ssh/sshd_config, изменяет порт и перезапускает сервис. Единственные вниз примыкают, то, что необходимо не забыть добавлять, что порт к конфигурации каждому ssh клиенту Вы используете.

Это абсолютно нормально в эти дни.
Можно настроить "пакетный" предел на брандмауэр для входящих новых соединений на порте SSH,
или установите один из многих синтаксических анализаторов a'la fail2ban журнала или измените порт SSH ;).

Последний является самым легким. На тяжелых загруженных машинах такие попытки взлома могут тяжелое действительно плохое влияние к целой системе.

--
С уважением,
Robert

Я использую pam_abl для временного помещения в черный список грубых садоводов, и это работает отлично. Я думаю, что чувствует себя лучше иметь авторизацию в PAM с помощью его собственной базы данных, а не зависеть от hosts.deny или iptables.

Другой плюс является этим pam_abl не зависит от сканирования файлов журнала.

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

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

Если Вам не нужен доступ в Интернет к SSH, отключают его. Если у Вас есть несколько известных адресов, которые нуждаются в удаленном доступе, ограничивают доступ к тем адресам.

Ограничение доступа к авторизованным ключам может также быть полезным.

Печально это довольно нормально. Необходимо полагать, что добавление чего-то как fail2ban к системе автоматически обнаруживает и запрещает взломщиков. Если Вы уже не делаете так, Вы должны также рассмотреть только использование ssh с открытыми ключами и не позволяете корневой вход в систему по ssh. Если ftp использования для передачи файлов системе рассмотрите использование scp/sftp вместо этого.

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

Пример:

AllowUsers admin jsmith jdoe

Опция AllowUsers указывает и средства управления, какие пользователи могут получить доступ к ssh сервисам. Многочисленные пользователи могут быть указаны, разделены пробелами.

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

Записи WHOIS локального ISPs помогли мне уменьшить нападения до 1-2 попыток входа в систему в месяц (тогда, это было о 1k/day). Я обнаружил тех, которые путем тихого использования denyhosts.

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

Неудавшиеся логины на нестандартных портах будут немногочисленны и могут также указать на более целенаправленные нападения.

Вы могли даже пойти шаг вперед установка ловушка SSH, такая как Kippo, чтобы 'впустить' bruteforcers и видеть то, что они сделают данный шанс.

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

Всегда будьте готовы быть взломанными.

Имейте копию своего веб-сайта на dev сервере. Это может быть Вашим рабочим столом Windows, использующим XAMPP, который можно получить бесплатно.

ВСЕГДА вносите изменения в свой dev сервер, затем загружают их на Ваш живой веб-сайт. Если это - CMS как Wordpress, заставьте свои сообщения на dev сервере затем скопировать и вставить их в живой сервер.

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

Контролируйте свои веб-страницы регулярно для любых изменений, которые Вы не сделали. А именно, скрытые ссылки на наркотики или продукты 'улучшения'. Можно найти, что много браузера добавляет ins и программы, которые сделают это для Вас.

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

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

Надеюсь, это поможет.

Довольно нормальный для наблюдения сотен неудавшихся соединений SSH.

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

Да,

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

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

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

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

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

Реализуйте правила IP-адреса для доступа SSH

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

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

Я сказал бы только, что получение только 500 является довольно низким.

В предыдущем работодателе звонил один из исследователей компьютерной безопасности, постоянный поток взлома делает попытку "Интернета, эквивалентного из космического шума". Он описал это как нормальный, непрерывный поток вредоносного трафика, который искал системы в Интернете, и автоматически используйте сценарии, чтобы попытаться угнать систему. Ботнеты и другие злонамеренные системы постоянно сканировали бы и повторно сканировали бы Интернет для уязвимых систем во многом как SETI.

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

используйте http://denyhosts.sourceforge.net/

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

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

Да. Это довольно нормально в наше время.

Используйте только аутентификацию с открытым ключом в административных целях, если это возможно. Генерируйте закрытый ключ на Вас рабочая станция:

$ ssh-keygen -t dsa

Copypaste содержание ~/.ssh/id_dsa.pub Вам серверы ~/.ssh/authorized_keys (и/root/.ssh/authorized_keys, должен Вы требовать прямого корневого входа в систему).

Настройте свои серверы/etc/ssh/sshd_config, чтобы только принять аутентификацию с открытым ключом:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

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

Изучите Denyhosts и fail2ban, чтобы заблокировать повторенные попытки входа в систему SSH и видеть Фырканье при требовании полного IDS/IPS.

Некоторые 100 очень хорошо... В прошлом месяце я нашел, что один из моих серверов имел 40k неудачные попытки. Я пошел канавка проблема вывести их на печать: Карта

После того как я изменил ssh порт и реализовал Стук Порта, число спало 0 :-)

Я для одного использования "tarpit" только в дополнение к разрешению аутентификации с открытым ключом и запрещению корневых логинов.

В netfilter существует a 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). Очевидно, можно использовать другие имена.

Перечислять или вычеркивать из списка использование дюйм/с:

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 у Вас есть еще одна опция: на самом деле обратитесь по адресу злоупотребления ISP взломщика. Это может казаться абсолютно бесполезным, но в случае деточки сценария их ISP более, чем готов принять меры на них.

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

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

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

• Уменьшите возможность для нападения при помощи fwknop

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

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

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

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

Просто посмотрите на последний аккомпанемент pwn2own, чтобы видеть, насколько легкий это для квалифицированного взломщика для взлома полностью исправленного администраторского поля.

• Отключить вход в систему root (в каждой системе Linux есть пользователь root, поэтому боты могут легко угадать имя пользователя) .После входа в систему как обычный пользователь вы можете switch to root either by su or sudo.

• change default port from 22

• Allow ssh access from known ip's only

• Use a strong alpha-numeric-password for the user with ssh access