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

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

196 голосов | спросил Kyle 8 MarpmTue, 08 Mar 2011 14:26:32 +03002011-03-08T14:26:32+03:0002 2011, 14:26:32

22 ответа


207

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

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

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

  • запретить root-login в SSH ( howto )
  • используйте надежные пароли везде (также в ваших веб-приложениях).
  • для SSH используйте аутентификацию с открытым ключом, если это возможно, и полностью отключите пароль-auth ( howto )

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

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

ответил Holger Just 8 MarpmTue, 08 Mar 2011 14:35:45 +03002011-03-08T14:35:45+03:0002 2011, 14:35:45
58

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

Как только я изменил порт ssh и реализовал Port Knocking, число упало до 0: -)

ответил Bart De Vos 8 MarpmTue, 08 Mar 2011 14:36:14 +03002011-03-08T14:36:14+03:0002 2011, 14:36:14
29

I для одного используйте «tarpit» в дополнение к разрешению аутентификации открытого ключа и запрету входа root.

В netfilter есть модуль 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, хотя я без проблем работал с ним без ограничений и только с приведенными выше правилами.

EDIT:

Можно заблокировать себя, делая это, поэтому вы можете добавить что-то вроде следующего, что позволяет вам очистить вас от запрета, постукивая по определенному порту:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove
ответил 0xC0000022L 8 MarpmTue, 08 Mar 2011 17:24:28 +03002011-03-08T17:24:28+03:0005 2011, 17:24:28
15

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

ответил Jacob 8 MarpmTue, 08 Mar 2011 14:32:18 +03002011-03-08T14:32:18+03:0002 2011, 14:32:18
12

Да . В настоящее время это нормально.

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

$ ssh-keygen -t dsa

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

Настройте серверы /etc /ssh /sshd_config только для проверки подлинности открытого ключа:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

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

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

ответил jkj 10 MaramThu, 10 Mar 2011 02:32:28 +03002011-03-10T02:32:28+03:0002 2011, 02:32:28
8

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

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

ответил number5 9 MarpmWed, 09 Mar 2011 12:37:50 +03002011-03-09T12:37:50+03:0012 2011, 12:37:50
6

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

ответил adamo 8 MarpmTue, 08 Mar 2011 14:33:23 +03002011-03-08T14:33:23+03:0002 2011, 14:33:23
6

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

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

ответил James Schek 8 MarpmTue, 08 Mar 2011 20:06:09 +03002011-03-08T20:06:09+03:0008 2011, 20:06:09
6

Да,

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

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

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

Использовать VPN для доступа к SSH

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

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

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

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

ответил Ben DeMott 9 MaramWed, 09 Mar 2011 00:56:48 +03002011-03-09T00:56:48+03:0012 2011, 00:56:48
5

Довольно нормально видеть сотни неудачных SSH-соединений.

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

ответил Adrian Macneil 8 MarpmTue, 08 Mar 2011 14:43:02 +03002011-03-08T14:43:02+03:0002 2011, 14:43:02
5

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

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

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

ответил JRW 8 MarpmTue, 08 Mar 2011 21:20:27 +03002011-03-08T21:20:27+03:0009 2011, 21:20:27
4

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

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

Вы даже можете пойти еще дальше, чтобы установить SSH honeypot, например Kippo , чтобы «пускай» в зверских бойцов и посмотрим, что они сделают, предоставив шанс.

ответил Andy Smith 9 MarpmWed, 09 Mar 2011 13:34:43 +03002011-03-09T13:34:43+03:0001 2011, 13:34:43
4

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

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

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

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

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

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

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

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

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

ответил J Litten 11 MarpmFri, 11 Mar 2011 19:51:46 +03002011-03-11T19:51:46+03:0007 2011, 19:51:46
3

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

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

ответил weeheavy 8 MarpmTue, 08 Mar 2011 15:27:47 +03002011-03-08T15:27:47+03:0003 2011, 15:27:47
3

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

Пример:

AllowUsers admin jsmith jdoe
  

Параметр AllowUsers указывает и   элементы управления, к которым пользователи могут обращаться к ssh   Сервисы. Множество пользователей могут быть   указанный, разделенный пробелами.

ответил Jay 9 MarpmWed, 09 Mar 2011 19:58:32 +03002011-03-09T19:58:32+03:0007 2011, 19:58:32
3

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

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

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

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

  • Укрепить авторизацию ssh с помощью Google-authenticator или wikid

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

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

ответил Hilton D 12 MaramSat, 12 Mar 2011 04:28:57 +03002011-03-12T04:28:57+03:0004 2011, 04:28:57
1

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

ответил Iain 8 MarpmTue, 08 Mar 2011 14:36:51 +03002011-03-08T14:36:51+03:0002 2011, 14:36:51
1

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

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

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

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

ответил BillThor 8 MarpmTue, 08 Mar 2011 18:54:39 +03002011-03-08T18:54:39+03:0006 2011, 18:54:39
0

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

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

ответил Christoffer Hammarström 9 MarpmWed, 09 Mar 2011 16:06:55 +03002011-03-09T16:06:55+03:0004 2011, 16:06:55
0

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

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

- Страница С уважением,
Роберт

ответил Robert 10 MaramThu, 10 Mar 2011 01:56:27 +03002011-03-10T01:56:27+03:0001 2011, 01:56:27
0

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

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

ответил John 11 MarpmFri, 11 Mar 2011 20:06:26 +03002011-03-11T20:06:26+03:0008 2011, 20:06:26
0
  • Отключить вход в корневой каталог (в каждой системе Linux есть пользователь root, поэтому боты могут легко угадать имя пользователя). После входа в систему как обычного пользователя вы можете переключитесь на root либо su, либо sudo.

  • изменить порт по умолчанию из 22

  • Разрешить доступ к ssh только из известных IP-адресов

  • Используйте сильный буквенно-цифровой пароль для пользователя с доступом ssh

ответил Kevin Parker 8 AM00000080000003831 2012, 08:24:38

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132