Как защитить / отследить ваш сайт от сканирования злоумышленником - PullRequest
2 голосов
/ 22 декабря 2008

Положение:

  • Сайт с контентом, защищенным именем пользователя / паролем (не все контролируются, так как они могут быть пробными / тестовыми пользователями)
  • обычная поисковая система не может получить доступ из-за ограничений имени пользователя / пароля
  • злоумышленник по-прежнему может войти в систему и передать куки-файл сеанса в "wget ​​-r" или что-то еще.

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

Я могу придумать несколько вариантов:

  1. Настройте некоторое решение для мониторинга трафика, чтобы ограничить количество запросов для данного пользователя / IP.
  2. Относится к первому пункту: автоматически блокировать некоторых пользовательских агентов
  3. (Зло :)) Установить скрытую ссылку, которая при обращении выходит из системы пользователя и отключает его учетную запись. (Предположительно, это не будет доступно обычному пользователю, поскольку он не увидит его, чтобы щелкнуть по нему, но бот будет сканировать все ссылки.)

По пункту 1. Знаете ли вы о хорошем уже реализованном решении? Есть опыт? Одной из проблем может быть то, что некоторые ложные срабатывания могут появиться для очень активных, но человека пользователей.

По пункту 3: вы думаете, это действительно зло? Или вы видите возможные проблемы с ним?

Также принимаем другие предложения.

Ответы [ 9 ]

5 голосов
/ 22 декабря 2008

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

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

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

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

2 голосов
/ 22 декабря 2008

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

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

Разновидностью пункта 3 будет отправка уведомления владельцам сайтов, после чего они смогут решить, что делать с этим пользователем.

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

edit: Связано, у меня когда-то была странная проблема, когда я получал доступ к своему URL, который не был общедоступным (я просто создавал сайт, который я нигде не объявил или не связывал). Хотя никто не должен был знать этот URL, кроме меня, внезапно я заметил попадания в журналы. Когда я разыскал это, я увидел, что это было с какого-то сайта фильтрации контента. Оказалось, что мой мобильный интернет-провайдер использовал стороннюю систему для блокировки контента, и он перехватывал мои собственные запросы - поскольку он не знал сайт, он затем выбрал страницу, к которой я пытался получить доступ, и (я предполагаю) провел некоторый анализ ключевых слов Чтобы решить, стоит ли блокировать. Это может быть случай, когда вам нужно остерегаться.

1 голос
/ 22 декабря 2008

Краткий ответ: это невозможно сделать надежно.

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

1 голос
/ 22 декабря 2008

В зависимости от того, о каком злонамеренном пользователе идет речь.

Если они знают, как использовать wget, они, вероятно, могут настроить Tor и каждый раз получать новый IP, медленно копируя все, что у вас есть. Я не думаю, что вы можете предотвратить это, не доставляя неудобств вашим (платящим?) Пользователям.

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

0 голосов
/ 07 января 2009

Apache имеет несколько модулей ограничения пропускной способности по IP-адресам AFAIK, и для моего собственного крупного Java / JSP-приложения с большим количеством цифрового контента я применил свой собственный фильтр сервлетов, чтобы сделать то же самое (и ограничил одновременные соединения из одного блока IP, и т.д.).

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

Rgds

Damon

0 голосов
/ 22 декабря 2008

Добавлены комментарии:

  • Я знаю, что вы не можете полностью защитить то, что должен видеть обычный пользователь. Я был на обеих сторонах проблемы:)
  • Что, по мнению разработчика, является лучшим соотношением времени, проведенного в сравнении с защищенными случаями? Я предполагаю, что некоторые простые проверки пользовательского агента удалили бы половину или более потенциальных сканеров, и я знаю, что вы можете потратить месяцы на разработку, чтобы защитить от последних 1%

Опять же, с точки зрения поставщика услуг, меня также интересует, что один пользователь (сканер) не использует ЦП / пропускную способность для других, так что вы можете указать какие-либо хорошие ограничения пропускной способности / запроса?

ответ на комментарий: Характеристики платформы: Приложение на основе JBoss Seam, работающее на JBoss AS. Однако перед ним стоит apache2. (работает на Linux)

0 голосов
/ 22 декабря 2008

http://recaptcha.net

Либо каждый раз, когда кто-то входит в систему, либо во время регистрации. Может быть, вы могли бы показать капчу каждый десятый раз.

0 голосов
/ 22 декабря 2008

@ frankodwyer:

  • Только доверенные пользовательские агенты не будут работать, особенно если учесть строку пользовательского агента IE, которая изменяется аддонами или .net версией. Было бы слишком много возможностей, и это можно было бы подделать.
  • вариант пункта 3. с уведомлением администратора, вероятно, сработает, но это будет означать неопределенную задержку, если администратор не будет постоянно отслеживать журналы.

@ Грег Хьюгилл:

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

Случайно изменить logout / disable-url для 3. было бы интересно, но пока не знаю, как бы я это реализовал:)

0 голосов
/ 22 декабря 2008

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

...