Black#FFFFFF
Постоялец
- Регистрация
- 19 Июл 2007
- Сообщения
- 228
- Реакции
- 172
- Автор темы
- #1
Задача (алгоритм) :
реализовать для не очень умных парсинговых скриптов защиту от парсинга страниц средствами php со временным баном особо наглых без ущерба для поисковой выдачи/быстроты получения страниц пользователями.
Собственно нужны мысли (советы) :
- от SEO шников
- от программистов
- от системных администраторов
1) есть ли готовые решения (не обязательно php) (не предлагать Cloudflare, ибо они как попало перенаправляют трафик при любых пакетах, а гуляния пользователей: СНГ - Индия - Китай - США - СНГ позитива не добавляют)
2) мысли по построению защиты (мои) :
а) кол-во запросов с одного айпи с обратным dns запросом (и пропуском поисковых ботов - если у кого есть список, был бы благодарен) в минуту, если больше определенной величины - в бан на время (с записью в лог ip).
б) отсеивание тех, кто вернул не правильный айпи адрес, вообще не представился | filter_var([ip], FILTER_VALIDATE_IP)
в) заголовки (набор заголовков) супер глобального массива SERVER для определения прозрачных proxy
'REMOTE_ADDR',
'HTTP_VIA',
'HTTP_X_FORWARDED_FOR',
'HTTP_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_FORWARDED',
'HTTP_CLIENT_IP',
'HTTP_FORWARDED_FOR_IP',
'VIA',
'X_FORWARDED_FOR',
'FORWARDED_FOR',
'X_FORWARDED',
'FORWARDED',
'CLIENT_IP',
'FORWARDED_FOR_IP',
'HTTP_PROXY_CONNECTION',
'HTTP_X_FORWARDED_SERVER'
можно дополнить, или дать ссылку на полный список подобных заголовков, если кто где собирает.
г) можно ли определить NAT? возможно не только средствами php, но и (например) библиотеками web сервера? (пока что мысли: если ip один, user agent разные, страницы запросов разные, и не выходят за кол-во адекватных конкурентных запросов в интервал времени, но здесь сложновато будет проверять)
в) Проверка Cookie/XHR Request еще актуальна? или к данному моменту это уже моветон?
д) Приветствуются мысли по построению быстрой проверки, исключая проверку портов и т.п., чтобы не снизить время получения нормальными пользователями обычных страниц.
ж) Приветствуется конструктивная критика: почему так не делать с аргументацией.
з) Как на Ваш взгляд хранить списки IP для более быстрой проверки/считывания (формат)? key:ip as int = val: кол-во запросов: массив? или как быстрее?
и) проверять ли: определен ли referer?
Можете дополнить. Рад любым мыслям. Реализация не нужна. Разрабатываем алгоритм.
После разработки алгоритма поделюсь своей реализацией/и некоторое время на общественных началах в случае с php реализацией готов дорабатывать/править с размещением, скажем, на Github.
Тестовой площадкой будет магазин до 20 тысяч пользователей в сутки/3-4 тыс страниц в поисковом индексе/2-3 тыс уник товаров.
реализовать для не очень умных парсинговых скриптов защиту от парсинга страниц средствами php со временным баном особо наглых без ущерба для поисковой выдачи/быстроты получения страниц пользователями.
Собственно нужны мысли (советы) :
- от SEO шников
- от программистов
- от системных администраторов
1) есть ли готовые решения (не обязательно php) (не предлагать Cloudflare, ибо они как попало перенаправляют трафик при любых пакетах, а гуляния пользователей: СНГ - Индия - Китай - США - СНГ позитива не добавляют)
2) мысли по построению защиты (мои) :
а) кол-во запросов с одного айпи с обратным dns запросом (и пропуском поисковых ботов - если у кого есть список, был бы благодарен) в минуту, если больше определенной величины - в бан на время (с записью в лог ip).
б) отсеивание тех, кто вернул не правильный айпи адрес, вообще не представился | filter_var([ip], FILTER_VALIDATE_IP)
в) заголовки (набор заголовков) супер глобального массива SERVER для определения прозрачных proxy
'REMOTE_ADDR',
'HTTP_VIA',
'HTTP_X_FORWARDED_FOR',
'HTTP_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_FORWARDED',
'HTTP_CLIENT_IP',
'HTTP_FORWARDED_FOR_IP',
'VIA',
'X_FORWARDED_FOR',
'FORWARDED_FOR',
'X_FORWARDED',
'FORWARDED',
'CLIENT_IP',
'FORWARDED_FOR_IP',
'HTTP_PROXY_CONNECTION',
'HTTP_X_FORWARDED_SERVER'
можно дополнить, или дать ссылку на полный список подобных заголовков, если кто где собирает.
г) можно ли определить NAT? возможно не только средствами php, но и (например) библиотеками web сервера? (пока что мысли: если ip один, user agent разные, страницы запросов разные, и не выходят за кол-во адекватных конкурентных запросов в интервал времени, но здесь сложновато будет проверять)
в) Проверка Cookie/XHR Request еще актуальна? или к данному моменту это уже моветон?
д) Приветствуются мысли по построению быстрой проверки, исключая проверку портов и т.п., чтобы не снизить время получения нормальными пользователями обычных страниц.
ж) Приветствуется конструктивная критика: почему так не делать с аргументацией.
з) Как на Ваш взгляд хранить списки IP для более быстрой проверки/считывания (формат)? key:ip as int = val: кол-во запросов: массив? или как быстрее?
и) проверять ли: определен ли referer?
Можете дополнить. Рад любым мыслям. Реализация не нужна. Разрабатываем алгоритм.
После разработки алгоритма поделюсь своей реализацией/и некоторое время на общественных началах в случае с php реализацией готов дорабатывать/править с размещением, скажем, на Github.
Тестовой площадкой будет магазин до 20 тысяч пользователей в сутки/3-4 тыс страниц в поисковом индексе/2-3 тыс уник товаров.
Последнее редактирование:
По сабжу: все это сейчас рассматриваю в виде дополнения к cms, и когда (на хостинге) нет возможности работать с п.о. сервера напрямую, поэтому и отрабатываю алгоритм и спрашиваю похожие мысли. В крайнем случае отправлю клиента на vds с хорошим решением. На основании set cookie, ajax/iframe + timestamp (rand request строка) в запросе сам писал мини защиты (но тоже лет 5 уже прошло), отшибало дурных ботов на ура. Но все идет, все меняется. Поэтому лишний раз спрошу/узнаю
, пришлось на шарпе обходить. В целом алгоритм не сложный, но заставил попариться, думаю такая штука отобъет у многих желание парсить