Как защитить/контролировать ваш сайт от обхода злоумышленником

Ситуация:

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

@frankodwyer:

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

@Greg Hewgill:

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

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

Ответ 7

http://recaptcha.net

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

Ответ 8

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

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

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

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

Ответ 9

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

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

Rgds

Дэймон