Стояла на PHP. Только не делала запросы rDNS, а отсеивала по готовому списку. В отличии от https не сильно грузит. Был и сейчас есть fail2ban, но это почти тоже самое по функционалу, что и на PHP, также по списку.
Nginx был бы самым идеальным вариантом. Либо какойто костыль к iptables или ipset.
Суть должна быть одна - не навредить поисковикам. Это не защита от DDOS, это всего лишь защита от ботов.
Несколько часов назад такой умник начал сканировать сайт из нескольких подсетей разной географии. Небольшой "ботнет". Сканирует пачками примерно по 100 страниц с одного ip. Сколько у него ip не знаю, более трех точно. Отсюда я и задумался. Временно его блокирнул по useragent в Nginx.
Сервер справляется, на диск ничего не свопит. Все индексы в ОЗУ. Всё можно сказать идеально. Вопрос то не в этом.
Со временем всё чаще и всё больше боты начинают сканировать сайт и контент со своего сайта вижу на просторах. Вот от них то и есть цель избавиться. Обычные юзеры+гуглоботы вообще не грузят сервер более 2%. Поэтому умощнять сервер с такой посещаемостью нет никакого смысла. У меня цель защитить его от нападков.
В основном просмотр. Insert в базу не более 10 тыс в день. Он вприницпе не заметен. Ну и PHP логгер в файл.. 1 запрос=1 запись.
Да как бы с самим сервером и ПО проблем нет, оптимизировать можно до бесконечности. Всё самописное и работает шустрее любых народных движков, в т.ч. фреймворка Yii. Вообще вопросов к части сервера и ПО нет. Я о методе отсеивания ботов в целом. Можно конечно выпендриваться и горизонтально развернуть свои сервера подобно яндексу, вопрос в целесообразности и цене. Когда можно отделаться более простыми решениями и пофиксить лишнюю нагрузку на самом обычном одиночном сервере. Мой на данный момент тянет свыше 2 млн просмотров за 10 часов, но логгер говорит о том, что армия ботов наступает настолько, что моментами нагрузка может в любую секунду превысить.
Если интересно: сервер 2 ядра и 3 гб ОЗУ, остальное на шустрых SSD, в цифрах не помню, но гораздо шустрее моего домашнего kingston KC300 по реальным тестам записи-чтения. Я повторюсь, у меня не 10-100 страниц, а 5 млн, с соответствующей базой MariaDB на движке Aria. Nginx+php5-fpm. Почти все 5 млн страниц используют полнотекстовый двиг по тем же 5млн строкам с сортировкой ASC-DESC, группировкой и JOIN. Программная нагрузка уже более чем приличная, и парадокс, но с ней нормально справился только Debian 8. И каждый бот внаглую сканирующий без паузы между запросами прилично отнимает ресурсов.
VDS на SSD. Шустрый. Вопросов к нему нет. Но с ростом посещаемости вопрос ботов тырящих контент с сайта растет в прогрессии. В конечном итоге получаем 502..504. Сайт в яндекс вебмастере падает на глазах. Падает в выдаче и понеслось. Лимит на количество запросов не актуален в обычном виде. На сервере куча сайтов, поисковики обращаются к ним на столько часто, что нет никакого смысла в лимитах. Чтобы поставить такой лимит в стандартном виде нужны белые списки ип адресов поисковиков, иначе они первые кто попадут под фильтр.
Дело в том, что я уже попадал в такую ситуацию. Когда количество ботов нагло сканирующих более 50 страниц в секунду растет и в конечном итоге сервер не справляется. Мой случай может достаточно редкий и для когото 150 запросов php страниц это мало (вордпресс на обычном дешевом vds вообще не тянет более 10 страниц в сек). Но и у меня не лэндинг, а портал с более чем 5 млн страниц использующие везде поисковик sphinx. В итоге 300 страниц в сек повесят сервак.
Сейчас rate от единичных ботов+yandex+google составляет примерно 5-15 страниц в сек круглосуточно, при этом load average выше 0.4 не подымается. Но еще пара таких ботов и сервер начнет медленно умирать.
Поставил ползунок на 20%. ну думаю, правило Паретто, вся фигня, наверно завалит мой сайт самыми сверхдорогими качественными объявами. И что я вижу? Оптимизацию в стиле Гугл - мимимум рекламы для посетителей, якобы дух качественного сайта, где нет рекламы вообще. Какой смысл в ограничении показов не понимаю. Ни о какой "умной" отсечке шлака там нет. Просто все объявления перестают показываться и заявленный прогнозируемй уровень дохода становится недостижимым. Почему бы не добавить список стоп слов, например я ввожу "Якубович", и нет больше этой ерунды. ПРИХОЖУ К ВЫВОДУ: либо делать как можно больше шлаковых сайтов и забить всю выдачу сателлитами, они их будут блокировать, а я буду создавать каждый день еще 30-100 штук новых с тизерной рекламой которая ничерта не окупается, либо уходить в оффлайн, продать компьютер и жить счастливо.
Помню Июнь 2014.. эх красота. Вся реклама строго релевантна title и тексту. А что теперь? Ты ввел в яндексе "купить киш-миш", тутже набрел на сайт, купил. Но зачем еще целый месяц догонять людей виноградом, да еще и шастая по другим абсолютно не тематиеческим сайтам???? И они считают ретаргетинг (ремаркетинг) крутой фишкой??? Бред.
Если Гугл будет так продолжать, то импортозамещение неминуемо. Мы лишь поможем Гуглу уйти из Российской Федерации. Я как бы не хочу совсем этого. Но мне не понятно, что они подкрутили в своих алгоритмах, что пошел один шлак. Уже примерно год показывается одна не релевантная реклама. Причем, отключать таргетирование по интересам или не отключать, никакой разницы не дает. Уже и тэги технические прописаны, для указания релевантного текста на страницах. ничего не помогает. То "фэйсбук", то "жена Путина", то еще всякий шлак по дешевым запросам в объвлениях. Видимо как поперла эта система ретаргетинга и объявления по интерессам пользователей (а не по релевантности тексту страниц) так всё и пошло к чертям. из-за этого и доход просел, и люди видят одно барахло на сайте, а потом ругаются, что это тут за грязная реклама.... Гугл... в погоне за баблом уничтожил свой идеальный алгоритм, от чего я сомневаюсь, что прибыль в их компании стала увеличиваться... кратковременно - то может да, но в долгосрочной перспективе, рекламодатели убегать начнут, когда нормальные люди рекламируют свои технические изделия для предприятий, а те показываются на сайтах для мамочек и в блоках на ютубе, на детских каналах и мультиках. Я просто сам лично это видел когда настраивал UTM метки в Эдвордсе... это был такой слив денег дичайший, что куча настроек тупо не помогала. Директ был гораздо эффективней.😡
автора топика можно смело забанить. удивительно как он в одном посте нарушил все правила адсенса. и ведь таким люди верят, а потом кричат везде, за что меня забанили. читайте официальные правила и не слушайте всех подряд советчиков.
Еще дополню про ssl stapling.
Про пост выше. Кое какие глюки остались, поэтому пошел дальше и закомментил к черту строку include /usr/local/ispmgr/etc/nginx.domain;, сделал распределение сертификатов в секциях server. Из секции http нужно удалить. Об этом ниже.
-----------------------------------------
Часто сижу на этом форуме, люди здесь мне помогают, решил тоже помоч кому нибудь, т.к. не мог найти интструкции которая бы заработала у меня.
Итак. Имеем сертификаты от StartSSL 2 штуки. Nginx обязательно обновляем до версии 1.8
Так как у меня 2 сервера с распределенной нагрузкой, я подписал их одним сертификатом, чтобы не запрашивались лишние сретификаты и не расла изза этого дополнительная нагрузка. StartSSL позволяет зарегистрировать сертификат на домен + субдомен. Ктото регает на субдомен вида www.site.ru, я же регал на subbomain.site.ru который у меня находится на 2 сервере. Отсюда возникла трабла, www получился без сертификата, что дало ошибку в неподписанном SSL на www.site.ru. Пришлось зарегать второй сертификат на этот же домен site.ru + "субдомен" WWW.site.ru Вообще наврено некорректно www называть субдоменом. Ну пускай будет им.
Я надеюсь понятно будет, мой первый сервер site.ru, второй сервер subdomain.site.ru, поэтому сертификат удачно разместился на двух физических серверах. Типа зачем? Надо мне так!
2 сертификат по сути был нужен только ради переадресации на site.ru без www. Т.к. в nginx ну и вообще по принципу работы SSL протокола, переадресация с www на без www при отсутствии второго сертификата не заработает. Можете проверить, как пример, зайдите на сбербанк онлайн или робокассу, и допишите к адресу www. Всё поймете. Для меня странно, что такие крупные конторы так наплевательски к этому отнеслись.
Короче, как сделать так чтобы при всей этой канителе заработал SSL стэплинг?
Да он собственно и без этой канители не работал, все инструкции что я находил были неполными, программерам не свойственно всё доходчиво объяснять, отсюда и инструкции как из жопы.
Разберу пример одного сервера, т.к. второй мой сервер ничем не отличается от первого кроме того что на нем установлен субдомен.
Итак, имеем ISPmanager-Lite 4.4.10.23, естественно с наикривейшей документацией.
Домены по стандарту создаем в панеле, указываем галочку SSL, выбираем сертификат введенный вручную. До этого его нужно создать в панеле с помощью копипастинга, инструкции найдете, они сносные, хотя тоже там запарка с последним нижнем полем, черт пойми какой сертификат вводить, вообще по хорошему туда нужно вводить промежуточный серверный с именем файла sub.class1.server.ca.pem, есть еще клиентский, будьте внимательны в названии. Вставлять так, чтобы на конце не было переноса и пробела, иначе ошибка.
Если SSL у вас заработал в стандартном конфиге, идем далее, настраиваем стэплинг.
Так будет выглядеть секция для редиректа с https www на https без www
server { server_name www.site.ru; listen 111.111.111.111:443 ssl spdy; ssl_certificate /var/www/httpd-cert/sss/cert.chained.crt; #это ключ самого сертификата, но прикол в том, что ISPmanager его уже объединил с промежуточным, и тем не менее стэплинг ничерта не работает. ssl_certificate_key /var/www/httpd-cert/sss/decryptprivat.key; #это ваш декриптованный private key, криптованный не заработает ssl_trusted_certificate /var/www/httpd-cert/sss/ca.pem; #а это чудо и есть наш файл для стэплинга, на название не смотреть, оно совпадает с названием некого сертификата от StartSSL, но готовится вручную иначе. ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 5m; ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8; add_header Strict-Transport-Security 'max-age=15778463'; return 301 https://site.ru$request_uri; }
Как приготовить сертификат для ssl_stapling в StartSSL?
Строгая последовательность!
Открываем наш Notepad++
Копируем и вставляем туда код сертификата выданный на домен, при скачивании со StartSSL он имеет как правило название вашсайт.crt либо копируйте из меню Retrieve Certificate на сайте StartSSL .
Смотрим чтобы после ---- не было пробелов, нажимаем энтер, копипастим следущий сертификат, с названием Class 1 Intermediate Server CA sub.class1.server.ca.pem (ВНИМАНИЕ, ТАМ СНОВА В НАЗВАНИИ server, есть такой же но client, у нас 1 класс, т.к. серт бесплатный), далее снова без пробелов и жмем энтер, с новой строки копипастим StartCom Root CA (PEM encoded) ca.pem.
Любой лишний пробел выпьет у вас крови.
Итого 3 сертификата.
Всё, сохраняем. Готово. Копируем в туже папку где остальные серты, ну и прописываем пути в nginx ssl_trusted_certificate /var/www/httpd-cert/sss/ca.pem;
service nginx restart
Забыл, это я привел пример конфиг редиректа, на основной конфиг всё тоже самое НО:
1. server_name site.ru;
2. без редиректа return 301 https://site.ru$request_uri;
3. все названия файлов сертификатов другие (это в моем случае, т.к. на www подключал другой серт, в вашем случае если серт выписали один на www и без www то все пути повторяются.
4. комментим строку отвечающую за доступ к ISP по адресу хх.хх.хх.хх:1500 #include /usr/local/ispmgr/etc/nginx.domain; иначе будете с бубном плясать как я.В IE под XP не будет работать и не будет работать редирект. браузер заматюкается на неподписанный серт ISP см. пост выше.
5.теперь доступ к ISP по адресу site.ru:1500, в том случае ели на вашем сервере 1 домен и он установлен по умолчанию к IP адресу сервера. Как проверить? Если заходим на хх.хх.хх.хх то перебрасывает на site.ru, ISP по адресу https://xx.xx.xx.xx:1500/ispmgr более не доступен, привыкайте.
6. Пункты 3-5 в вашем случае могут быть не нужны. остальные редиректы с http на https не привожу. Там главное помнить, что будет несколько секций server, отдельно под www http порты 80 и 443.
Как проверить что всё гууд?
1. Проверяем на логи ошибок nginx. Заходим на сайт, смотрим ошибки. Если есть типа 4567#0: OCSP_basic_verify() failed (SSL: error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:Verify error:unable to get issuer certificate) while requesting certificate status, responder: ocsp.startssl.com значит вы накосячили.
На сайт заходить только с винды выше XP и с браузером chrome, На ХР степлинг не работает! На многих браузерах тоже.
2. Если ошибок нет, то тестим дальше.
3. Заходим в консоль, команда
openssl s_client -connect site.ru:443 -tls1 -tlsextdebug -status < /dev/null| grep OCSP
Если всё правильно выдает кучу текста про сертификаты и их промежутки а также OCSP Response Data: OCSP Response Status: successful (0x0)
Если ошибка то... OCSP response: no response sent
3. Тестим наш серт. https://www.ssllabs.com/ssltest/index.html После окончания внизу примерно будет зеленая строка OCSP stapling Yes.
4. Идем в магазин за пивом. Купите дешманское - работать перестанет.
