Вы здесь

Борьба со спамом и Интернет-ботами. Часть 3

couple looking at computer screen
                                 И вечный бой! Покой нам только снится
                                 Сквозь кровь и пыль...
                                 Летит, летит степная кобылица
                                 И мнет ковыль...
                                                                А.Блок

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

 
 
Гео-блокировка
 
Адреса IPv4 давно исчерпаны, поделены, куплены-перекуплены, и их нынешние хозяева вряд ли скоро сменятся. Значит, этот факт мы можем использовать. Не секрет, что спамеры и взломщики не брезгуют заходить на сайт с любых направлений (разных сетей, стран и континентов). Что делать? Сесть и подумать. Пролистав «список посещений» сайта или достав «тайные планы», можно решить, кто, скорее всего, не будет (или не должен) его смотреть, а кто соответствует нашей «целевой аудитории».
 
Хотя мой сайт содержит англоязычные страницы, я точно знаю, что африканские страны (за исключением ЮАР), скорее всего не будут интересоваться его материалами. Большинству стран ЮВА он тоже не пригодится. Значит, можно смело их отбросить. Плохой ли это ход? Плохой, но мне в первую очередь необходимо упростить себе задачу и уменьшить нагрузку (ну нет у меня специальных людей и дополнительного свободного времени) – а значит, вполне допустимо.
 
Что нам известно? Есть некая «Корпорация по управлению доменными именами и IP-адресами» (ICANN), которая занимается регулированием вопросов, связанных с доменными именами, IP-адресами и прочими аспектами функционирования Интернета. Уже неплохо. Так же, в мире сейчас всего 5 региональных интернет-регистраторов (RIRs), которые заведуют каждый своим участком, примерно соответствующего определённой части света.
 
Для решения вопросов с управлением IP-адресов, ICANN пользуется услугой компании IANA. IANA делегирует свои полномочия по распределению IP-адресов региональным регистраторам в виде диапазонов класса A («/8»). Региональные регистраторы, в свою очередь, делегируют более мелкие диапазоны интернет-провайдерам. Следовательно, нужные данные мы найдём у IANA или у соответствующего RIR-а (у них есть свои сайты).
 
Странами Африки и региона Индийского океана занимается регистратор под именем AfriNIC. Его диапазоны адресов мы можем взять прямо из открытых источников. К сожалению, данные в Википедии по другим регистраторам не полны, но у нас есть первоисточник от IANA. Если интересно вообще «покопаться» в теме, то здесь вполне и конкретно много чего указано. Читайте и обрящете.
 
А я пока записал в .htaccess следующие строки:
 
       # Блокируем африканский диапазон (AFRINIC)
      deny from 41.0.0.0/8 102.0.0.0/8 105.0.0.0/8 154.0.0.0/8 196.0.0.0/8 197.0.0.0/8
 
Всё, Африку, «как языком слизало»! «Полковнику никто не пишет…» (с)
 
Как говорят англичане, их потеря – суть нашего приобретения, а их приобретение – наша потеря. Где-то что-то должно быть не так… «А ларчик открывается просто»: поисковые системы (и многие другие компании) разбросаны по всему миру и очень не любят когда их в чём-то ограничивают. Например, «Гугл». Его филиалы и сервера могут находиться где угодно. И робот-поисковик может зайти как с американских адресов, так и с европейских.
 
А есть ли «Гугл» в Африке? Для начала вспоминаем, что Google – американская компания, а значит, для уточнения его данных нам нужен APNIC (хотя, IANA тоже сгодится): зайдём на сайт и введём его имя «google». Получаем список компаний, содержащих это слово, регистрационные данные и выделенные адреса. Т.к. собирать информацию по крохам неудобно («Гугл» отметился не только здесь), я взял правильное регистрационное имя «Google Inc.» (будьте внимательны, компании могут иметь разные имена) и обратился к другому сборщику данных.
 
Кстати, если интересно, вот регистрационная информация Яндекса в APNIC. Его я тоже смотрел... Возвращаемся к теме. Итак, мы открыли страничку MyIP.ms, в строке поиска ввели «Google Inc.» и получили список всех выделенных адресов компании с указанием выдавшего регистратора. Для удобства я, например, выгрузил его в Excel, отсортировал и нашёл два диапазона в Африке (AfriNIC). Осталось проконтролировать: открываем страницу поиска на сайте IANA и вводим любой контрольный адрес. Сверяем полученные данные о регистраторе, диапазоне и кому он выделен.
 
Делаю уточнение в файле .htaccess:
 
      # Для удобства управления исключениями, даём приоритет allow,
      # чтобы оно перебивало deny
      Order deny,allow
 
      # Блокируем африканский диапазон (AfriNIC)
      deny from 41.0.0.0/8 102.0.0.0/8 105.0.0.0/8 154.0.0.0/8 196.0.0.0/8 197.0.0.0/8
 
      # Исключение: Google из Кении и ЮАР
      allow from 41.206.47.0/25
      allow from 41.206.188.128/26
 
Ну вот, порядочек. Можно сделать проще? Можно. Для «лентяев» в Друпале уже давно существует масса модулей, позволяющих блокировать доступ из стран и континентов. Кому надо – найдёт самостоятельно! :) Ну, а я сделал это «ручками». Из-за какой-то Африки с четырьмя строками я буду ставить целый модуль? Обойдутся. К тому же, блокировка на уровне сервера намного быстрее. А мне не лень!
 
Блокировать адреса какой-то компании ещё проще, достаточно в каком-то интернет-агрегаторе (типа MyIP.ms) сделать поиск по имени, и получить искомый список для записи в «.htaccess». Со странами немного сложнее. Например, меня в своё время «достали» китайские спамеры (точнее те, кто работали в их диапазоне). Реально оттуда не было ни одного читателя, а проблем – «вагон и маленькая тележка».
 
Значит, «резать». Есть специализированные сайты, предоставляющие информацию по странам. Например, IPDeny. (Кстати, сайт полезный, предоставляющий разную информацию и инструментарий). Заходим в раздел стран, находим Китай. Скачивать лучше «aggregated zone file» - он короче (за счёт «упаковки» адресов). Всё, вот мы и получили список IP-диапазонов нужного государства. Осталось обработать и включить.
 
Работать с сайтом стало проще. И, в конечном итоге (поначалу помогало сильнее), лог сайта «разгрузился» процентов на 10. А это хорошо!
 
 
Фальшивые роботы
 
Регулярно просматривая логи сервера, вы наверняка замечали некоторые странные обращения, а глянув на User-Agent пришельца – с недоумением обнаруживали подпись Google-робота (или какого другого). Как определить «фальшивку»? Пробить по адресу. Если это адрес поисковика – значит всё верно, иначе его надо блокировать. Краткая статья от самого «Гугла». Плюс оригинальный список действующих роботов. А как ещё можно? Можно выполнить запрос и получить «reverse dns». Например:
 
nslookup 66.249.66.1
 
Name: crawl-66-249-66-1.googlebot.com
Address: 66.249.66.1
 
Или так:
 
ping -a 66.249.66.1
 
Обмен пакетами с crawl-66-249-66-1.googlebot.com [66.249.66.1] по 32 байт:
 
Ответ от 66.249.66.1: число байт=32 время=137мс TTL=42
Ответ от 66.249.66.1: число байт=32 время=137мс TTL=42
Ответ от 66.249.66.1: число байт=32 время=137мс TTL=42
Ответ от 66.249.66.1: число байт=32 время=137мс TTL=42
 
Статистика Ping для 66.249.66.1:
Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
Минимальное = 137мсек, Максимальное = 137 мсек, Среднее = 137 мсек
 
Это шутка. Всегда надо ориентироваться только на официальные данные. Вполне могут сделать фальшивку, и она вам ответит как Google.
 
 
Сборщики информации
 
Время от времени мой сайт подвергается нашествиям, когда одномоментно идут запросы с разных адресов (стран и континентов). Сомневаюсь, что это чистый DDoS (моя важность не так велика). Хотя лог сервера за каждую минуту такого нападения может составлять много страниц. Эти атаки пока непродолжительны (от силы несколько часов), и среди записей чётко просматриваются интересные User-Agent-ы. Например:
 
Is Down For Everyone or Just Me? (+http://isdownforeveryone.me)
TipTop http://feeltiptop.com
CSE HTML Validator Online (http://www.OnlineWebCheck.com) via 115.248.237.77
aboutthedomain
Genderanalyzer/1.0
http_requester/0.1
MagpieRSS/0.72 (+http://magpierss.sf.net)
SimplePie/1.2.1-dev (Feed Parser; http://simplepie.org; Allow like Gecko) Build/20130218105852
libwww-perl/6.06
PHX HTTP Client
RankFlex.com Webspider
W3C_Validator/1.3 http://validator.w3.org/services
 
Ага, я их коллекционирую. :)
 
Перед взломом сайта «нормальные герои» обычно проводят его исследование на ценность: рейтинг, возможная сумма заработка, место регистрации, данные о владельце. Пытаются получить список зарегистрированных пользователей и всё о них. Собирают СЕО-информацию (целевая группа, откуда и как заходят, что пишут, читают), технические данные («движок», модули, их версии и пр.)
 
Чаще всего это маскируется под DDoS, когда в одну и ту же минуту приходят десятки запросов с разных адресов, но каждый из них выполняет свою функцию. А что тут такого: с этого адреса мы решили зайти «первым» пользователем, с этого – проверили наличие скрипта контактов, а здесь у нас пришёл робот проверить гендерную принадлежность авторов материалов, а этот – все лишь спросил файл «robots.txt» или «update.txt».
 
Ну и пара-тройка уважаемых сайтов вдруг решила послать своих ботов собрать инфу об используемых модулях, версии, проверить их уязвимость, а заодно – HTML-кода страничек… Ничего личного, только бизнес. :) Такая вот пятиминутка «ненависти»… Как правило, это у меня происходит один-два раза в месяц. Но пару раз было и до недели, т.е. в течение семи дней с часовыми перерывами (40-50 мин)…
 
Вскоре после такого «наката» уже видны вполне осмысленные попытки подбора ключей…
 
Большинство данных сейчас легко получить из «открытых» источников, сделав запрос на специализированном сайте – его робот придёт и соберёт всё, что нужно, а заказчик заберёт готовое. Кроме спец-программ, в сети полно сайтов для СЕО и разработчиков, предоставляющие услуги по «парсингу», проверки регистрации, подлинности (валидации) и анализа уязвимостей.
 
Защититься от уникальных вещей крайне трудно. Ну, а от типовых – можно. Роботы-сканеры исследовательских сайтов и обращения, созданные с использованием специализированных инструментов, имеют вполне чёткие User-Agent-ы. Поэтому, если это не мы исследуем сайт, то кто? Кто озаботился проверкой HTML-разметкой нашего «малыша»? «Кто вы такие и где мои деньги?» (с)
 
Вопрос: а если я сам захочу протестировать безопасность моего сайта? Ответ: очень просто – локально (для этого есть инструменты). А если это не подойдёт – временно, пока проверяем, разрешить определённые агенты (UA) или IP-адреса «тестеров».
 
 
Блокировка методов обращения к сайту
 
Ещё одна интересная тема – методы обращения HTTP к серверу. И с этим стоит разобраться. Ну-ка, чем же занят мой посетитель? Про вашего – не знаю, а мой – листает блог или пишет комментарий. А это значит, «что не страшны тебе ни горе, ни беда»… Короче, я могу ограничить список допустимых методов всего двумя: GET и PUT. А остальное – буду считать недопустимым. (Зачем им то, чего нет?). :)
 
Поэтому, я уже давно переделал свой .htaccess-файл (по сравнению с первыми частями статьи) примерно к такому виду:
 
# Для правильной работы требуется мод "mod_authz_host"
<IfModule mod_authz_host.c>
 
   # Все методы, кроме GET и POST - запрещаем
   <LimitExcept GET POST>
      Order deny,allow
      deny from all
   </LimitExcept>
 
   # Можно использовать методы GET и POST
   <Limit GET POST>
 
      # Для удобства управления исключениями, даём приоритет allow,
      # чтобы оно перебивало deny
      Order deny,allow
 
      # Блокируем африканский диапазон (AfriNIC)
      deny from 41.0.0.0/8 102.0.0.0/8 105.0.0.0/8 154.0.0.0/8 196.0.0.0/8 197.0.0.0/8
 
      # Исключение: Google из Кении и ЮАР
      allow from 41.206.47.0/25
      allow from 41.206.188.128/26
   </Limit>
</IfModule>
 
Если настройки, связанные с блокировкой плохих User-Agent-ов и пр. (см. предыдущие части статьи), разместить после этих строк, тогда применять в них повторное ограничение по методу запроса – необязательно. Они же идут ниже основной блокировки по методам и диапазону адресов, а значит – это уже будет сделано.
 
 
Блокировка «старых» агентов
 
Очень простая профилактика – блокировка агентов, «вышедших из употребления». Часть ОС и Интернет-браузеров сейчас уже не поддерживаются и не используются. А вот боты с их «подписью» «гуляют, где попало». Как такое может быть? Никак. Это «вредители». Как узнать, что отмерло? Навскидку можно сказать, что из-под «Виндовс» версии ниже XP вряд ли кто-то выходит в Инет… Можно отсечь варианты связанные с более ранними ОС и «древние» браузеры, которые уже не работают на WinXP SP3.
 
Даю, как пример (у меня чуть по-другому). Надеюсь, вы знаете, куда и как это вписать:
 
      SetEnvIfNoCase User-agent [\s\(]Win(dows)?(\s)?(3|9x|95|98|ME|2k|2000)[;\)\s\./] GoAway=1
      SetEnvIfNoCase User-agent [\s\(]MSIE\s[0-5]\. GoAway=1
      SetEnvIfNoCase User-agent ^Mozilla/[0-3]\. GoAway=1
 
И проделать такой анализ не только по IE, но для FireFoх, Opera и пр.
 
Определённую информацию о спецификации от Microsoft можно почерпнуть здесь. По «ОгнеЛису» я почитал на специализированном форуме. И да поможет вам хороший сайт со списками разных «агентов», рассортированных по типу и версиям (будьте внимательны, там есть и ошибки). Так что, тот бред, когда ко мне приходили пользователи с агентами чуть ли не от ДОС-а – давно уже закончился.
Попробуйте, у вас получится. :)
 
 
Блокировка плохо сделанных агентов
 
Мы не можем вести бесконечный список плохих «Юзер-Агентов». Следовательно, любой простой способ «отделения овец от козлищ» – всегда «плюс в карму». В комментарии ко второй части статьи я обмолвился, что есть ещё один очень простой способ отсева и, возможно, я расскажу о нём. А основан он на правилах оформления User-Agent-ов (UA).
 
Очень часто спам-боты (и люди, которые этим занимаются) используют фальшивые агенты. Откуда они берутся? Кто-то сделал вручную, кто-то обратился за помощью к программе или сайту-генератору, воспользовался готовыми, «зашитыми» в программах рассылок сообщений или другими источниками. К счастью, во многих из них есть ошибки или заложены какие-то метки.
 
Ошибки бывают «синтаксические», «грамматические» и фактологические. Де-факто, существует некая общепринятая пунктуация. Грамматические – это неправильное написание слов и символов (с ошибками), а фактологические - несоответствие используемых наименований, версий и их комбинаций. Но, «пионеров» это никогда не волновало. На это мы и ловим!
 
До сих пор встречаются посетители с пустыми или слишком длинными UA. С первым случаем – ясно, его рассмотрели в прошлой части статьи. Естественно, ограничение по длине – есть. Раньше это было 256 символов. Если больше, Майкрософт вежливо предупредит при проверке агента (есть такой сервис для IE). А теперь расширено до 512. Следовательно, имеет смыл сделать аналогичное ограничение и в «.htaccess». «Врагам» никто не помешает сделать User-Agent длиннее, а мы их не пустим!
 
      SetEnvIf User-agent ^.{512}$ GoAway=1
 
Если «генератор» UA некачественный, он может сделать строки с нарушениями по «синтаксису». На тот момент, когда я применил свои правила, таких плохих агентов в логе (поначалу блокировал по IP) было от 10 до 20 процентов. На цифры не смотрите, это было именно «на тот момент». Тут как, если одних «вычеркнуть», то доля других вырастёт (математика!).
 
Обратившись к справочнику «Стэли» (шучу!), вывел набор простых правил (в Интернете документации не нашёл, но абсолютное большинство Юзер-Агентов их придерживается). Все не дам, но самые простые:
 
# Правила для агентов:
# 1. Текст User-agent всегда начинаются с буквы
# 2. "Слова" в User-agent всегда разделяются пробелами
# 3. Допускаются только одинарные пробелы
# 4. Дополнительный визуальный разделитель (кроме пробела) - ";"
# 5. После точки с запятой (;) всегда пробел, а перед ней - нет
# 6. Для группировки "Слов" могут применяться круглые скобки
# 7. Открывающая скобка: впереди должен быть пробел, а сзади - нет
# 8. Закрывающая скобка: сзади должен быть пробел (если не конец), а впереди – нет
 
Остальное вы допишите сами. Должны же вы чем-то заниматься? :)
(Продолжение следует)
 
 
01.12.2016 г. Карандаш.
 
 
P.S.: (21.02.2017)
         По поводу седьмого правила для UA (Открывающая скобка: впереди должен быть пробел, а сзади - нет). Здесь есть досадное исключение, в случае использования сжатия данных. Как правило, в таких агентах отображается дополнительная информация о gzip-архивации.
Например, в агенте программы Гугл-переводчика:
   Mozilla/5.0 (Windows NT 5.1; rv:51.0) Gecko/20100101 Firefox/51.0,gzip(gfe)
 
Стоит ли это учитывать - решать вам.
 
 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer