Масивна атака 404 з неіснуючими URL-адресами. Як запобігти цьому?


14

Проблема полягає в цілому навантаженні з 404 помилок, про які повідомляє Google Webmaster Tools, зі сторінками та запитами, яких там ніколи не було. Один з них є viewtopic.php, і я також помітив жахливу кількість спроб перевірити, чи є сайт WordPress ( wp_admin) і для входу cPanel. Я вже блокую TRACE, і сервер оснащений певним захистом від сканування / злому. Однак, схоже, це не зупиняється. За інформацією Google Webmaster, цей референт є totally.me.

Я шукав рішення, щоб зупинити це, оскільки це, безумовно, не добре для реальних реальних користувачів, не кажучи вже про проблеми, пов'язані з SEO.

Я використовую міні-чорний список Perishable Press ( знайдений тут ), стандартний блокатор рефералів (для порно, трав'яних сайтів, сайтів казино) і навіть деяке програмне забезпечення для захисту сайту (блокування XSS, ін'єкція SQL тощо). Сервер також використовує інші заходи, тож можна припустити, що сайт безпечний (сподіваємось), але він не закінчується.

Хтось ще має таку ж проблему, чи я єдиний, хто бачив це? Це те, що я думаю, тобто якась атака? Чи є спосіб виправити це, а ще краще запобігти цьому марному відходженню ресурсів?

EDIT Я ніколи не використовував питання, щоб подякувати за відповіді, і сподіваюся, що це вдасться зробити. Дякую всім за ваші проникливі відповіді, які допомогли мені знайти вихід із цього. Я дотримувався пропозицій усіх і реалізував таке:

  • медовий горщик
  • скрипт, який прослуховує підозрювані URL-адреси на сторінці 404 і надсилає мені електронний лист із користувачем-агентом / ip, повертаючи при цьому стандартний заголовок 404
  • скрипт, який нагороджує законних користувачів на тій же спеціальній сторінці 404, якщо вони в кінцевому підсумку натискають на один із цих URL-адрес. Менш ніж за 24 години мені вдалося виділити деякі підозрілі ІР-адреси, перелічені в Spamhaus. Всі зареєстровані IP-адреси поки що належать спам-хостинговим компаніям VPS.

Дякую ще раз, я б прийняв усі відповіді, якби міг.


Коли в Інструментах для веб-майстрів Google кажуть, що референт - це ви повністю, ви маєте на увазі, що вони вказують на те, що сторінки на вашому веб-сайті - це референтні сторінки?
Стівен Остерміллер

вибачте, моя помилка. У мене є ці сторінки, які ніколи не існували в інструментах для веб-майстрів, і Google каже, що їх не знайдено. Один з них - mysite.com/viewtopic.php?forget_the_value=1 і пов’язаний із Total.me.Я навіть натиснув ... Не знайшов нічого.
таттвамасі

2
Зазвичай, у ваші журнали доступу потрапляє багато 404 неіснуючих сторінок, перевірка наявності вразливих ситуацій (наприклад, адміністратора WP) тощо. - Вам просто потрібно переконатися, що ваш сайт захищений. Однак для того, щоб повідомити про них GWT, то чи є посилання на ці сторінки, або на вашому домені розміщувався попередній сайт (наприклад, WordPress)?
Містер Білий

ніпе. Найсмішніше те, що я ніколи не використовував wordpress, і я ніколи не використовував сторінки, які я бачив, як 404 помилки. Деякі помилки я викликав (помилкові URL-адреси у вхідних посиланнях, з однієї сторінки на іншу), але файлу viewtopic.php там ніколи не було. Цей сайт працює вже роками ...
tattvamasi

Коли я кажу "посилання на ці сторінки", я маю на увазі з інших сайтів . Для кожної з ваших 404 помилок (у GWT) ви повинні мати змогу деталізувати, щоб показати вам, звідки вона "пов'язана".
MrWhite

Відповіді:


17

Я часто бачу інший сайт, який посилається на тони сторінок на моєму сайті, які не існують. Навіть якщо ви натискаєте на цю сторінку і не бачите посилання:

  • На сайті, можливо, раніше були ці посилання
  • Цей веб-сайт може приховуватись і обслуговувати ці посилання лише на Googlebot, а не для відвідувачів

Це марна трата ресурсів, але це не заплутає Google і не зашкодить вашому рейтингу. Ось що Джон Google Мюллер (який працює над Інструментами для веб-майстрів та сайтами) повинен сказати про 404 помилки, що з’являються в інструментах для веб-майстрів :

ДОПОМОГА! МОЙ САЙТ МАЄ 939 ПОМИЛЬНИХ ПОМИЛКІВ 1

Я бачу подібне запитання кілька разів на тиждень; ви не самотні - багато веб-сайтів мають помилки сканування.

  1. 404 помилки щодо недійсних URL-адрес жодним чином не шкодять індексуванню або ранжируванню вашого веб-сайту . Не має значення, чи є 100 чи 10 мільйонів, вони не зашкодять рейтингу вашого сайту. http://googlewebmastercentral.blogspot.ch/2011/05/do-404s-hurt-my-site.html
  2. У деяких випадках помилки сканування можуть виникати з законної структурної проблеми на вашому веб-сайті або CMS. Як ти розповідаєш? Перевірте походження помилки сканування. Якщо на вашому веб-сайті є непрацездатне посилання, у статичному HTML вашій сторінці, це завжди варто виправити. (спасибі + Мартіно Мосна )
  3. Що з прискіпливими URL-адресами, які "чітко зламані?" Коли наші алгоритми люблять ваш сайт, вони можуть спробувати знайти на ньому більше чудового вмісту, наприклад, намагаючись відкрити нові URL-адреси в JavaScript. Якщо ми спробуємо ці "URL-адреси" і знайдемо 404, це чудово і очікувано. Ми просто не хочемо пропустити нічого важливого (сюди вставляйте надмірно доданий мем Googlebot). http://support.google.com/webmasters/bin/answer.py?answer=1154698
  4. Вам не потрібно виправляти помилки сканування в Інструментах для веб-майстрів. Функція «позначити як фіксовану» лише допомогти вам, якщо ви хочете відслідковувати свій прогрес там; це не змінює нічого в нашому конвеєрі веб-пошуку, тому сміливо ігноруйте це, якщо він вам не потрібен. http://support.google.com/webmasters/bin/answer.py?answer=2467403
  5. Ми перераховуємо помилки сканування в Інструментах для веб-майстрів за пріоритетністю, яка базується на кількох факторах. Якщо перша сторінка помилок сканування явно не має значення, ви, ймовірно, не знайдете важливих помилок сканування на інших сторінках. http://googlewebmastercentral.blogspot.ch/2012/03/crawl-errors-next-generation.html
  6. На вашому веб-сайті не потрібно «виправляти» помилки сканування. Пошук 404-х є нормальним і очікується від здорового, добре налаштованого веб-сайту. Якщо у вас є еквівалентна нова URL-адреса, то перенаправлення на неї є хорошою практикою. В іншому випадку ви не повинні створювати підроблений контент, ви не повинні перенаправляти на свою домашню сторінку, ви не повинні robots.txt забороняти ці URL-адреси - все це ускладнює нам розпізнавання структури вашого веб-сайту та обробку його належним чином. Ми називаємо ці "м'які 404" помилки. http://support.google.com/webmasters/bin/answer.py?answer=181708
  7. Очевидно - якщо ці помилки сканування відображаються для URL-адрес, які вас цікавлять, можливо, URL-адрес у вашому файлі Sitemap, то це те, на що слід негайно вжити заходів. Якщо Googlebot не може сканувати ваші важливі URL-адреси, вони можуть вийти з результатів пошуку, і користувачі також не зможуть отримати доступ до них.

дякую, хоча я читав про те, що хтось стверджує, що напад 404 негативно вплинув на їхній рейтинг сторінки (обговорення на форумі для веб-майстрів google, як тільки я його опублікую, я опублікую його тут), а деякі заявляють, що 404 помилок враховується (Google не говорять все, ці люди стверджують), тож це одна з моїх проблем, а інше питання - хто масово твітує неправильні посилання на мій сайт спеціально, і чому, якщо він не повинен робити нічого для SEO? Прийняв відповідь :)
tattvamasi

total.me - це справжній сайт. Існує багато тисяч сміттєвих сайтів, які скреблі і розміщують посилання для залучення користувачів. Це форма спамування. Іноді ці посилання існують лише короткий проміжок часу. Здебільшого це робиться для впливу на менші менш складні пошукові системи з більшою кількістю регіональних аудиторій, які найчастіше зустрічаються в Росії та Польщі, хоча є багато інших. Такі посилання часто надходять із баз даних, які були передані попередніми зусиллями зі скраплювання, так що старі посилання будуть повторюватися, а нові сайти періодично з'являтимуться. З цим нічого не можна зробити.
closetnoc

2
"Атака 404", безумовно, НЕ вплине на рейтинг сторінки вашого сайту, а також на його рейтинг. (Якщо ваші конкуренти витрачають час на посилання на сторінки 404, це менше часу, які вони витрачають на те, щоб зробити щось корисне, тому будьте щасливі :)). Сайти повинні мати 404, це знак того, що ви правильно налаштували сервер. , тож якщо що-небудь, це буде хорошим сигналом для нас.
Джон Мюллер

5

Існує багато сценаріїв, які оптимістично сканують випадкові IP-адреси в Інтернеті, щоб знайти вразливості, відомі в різних видах програмного забезпечення. У 99,99% часу вони нічого не знаходять (як на вашому сайті), і що 0,01% часу, скрипт буде забивати машину і робити все, що хоче контролер сценарію. Зазвичай цими сценаріями керують анонімні ботнети з машин, які раніше були pwnd, а не з фактичної машини оригінального малюка сценарію.

Що тобі слід робити?

  1. Переконайтеся, що ваш сайт не вразливий. Для цього потрібна постійна пильність.
  2. Якщо це створює настільки велике навантаження, що впливає на нормальну продуктивність сайту, додайте правило блокування на основі IP-адреси, щоб уникнути прийняття з'єднань з певного сайту.
  3. Навчіться фільтрувати сканування на CMD.EXE або cPanel або phpMyAdmin або тонни інших уразливостей при перегляді журналів сервера.

Ви, здається, вірите, що будь-який 404, повернутий з вашого сервера комусь, вплине на те, що Google думає про ваш сайт. Це не правда. На ваш сайт впливатимуть лише 404-ті, повернені сканерами Google, а можливо, і користувачами Chrome. Поки всі посилання на вашому веб-сайті є належними посиланнями, і ви не визнаєте недійсними посилання, які ви раніше зазнавали в світі, ви не побачите жодного впливу. Боти сценаріїв ні в якому разі не спілкуються з Google.

Якщо вас атакують по-справжньому, вам потрібно буде зареєструватися в якійсь службі постачальника послуг зі зменшення впливу DoS. Verisign, Neustar, CloudFlare і Prolexic - це всі постачальники, які мають різні види планів для різного роду атак - від простого веб-доступу (яке може бути безкоштовним у деяких постачальників) до DNS на основі фільтрації попиту, до повного BGP на основі перепадів точки присутності, який спрямовує весь ваш трафік через "очищення" центрів обробки даних з правилами, що пом'якшують атаки.

Але це звучить з того, що ви говорите, що ви просто бачите звичайні сценарії вразливості, які бачить будь-який IP в Інтернеті, якщо він прослуховується на порту 80. Ви можете буквально поставити нову машину, запустити порожній Apache, і через кілька годин ви почнете бачити ці рядки в журналі доступу.


велике спасибі - я буду шукати додаткові фільтри, хоча захист сервера та сайту настільки високий, що іноді законний користувач уже потрапляє на заборонену сторінку. У відповідь на "Тільки 404, які повернулися сканерами Google, і, можливо, користувачами Chrome", я мушу додати, що я знайшов ці посилання в Інструментах Google для веб-майстрів, тож я можу з упевненістю припустити, що їх сканують ...
tattvamasi

Вам потрібно з’ясувати, чому Google потрапляє на ці неіснуючі сторінки. Наприклад, якщо ви впустите сторонні сторони у свої журнали доступу, то це буде можливим способом Google дістатись до них. Ви не повинні пускати сторонніх учасників до них. Крім того, безпека набагато більше стосується чітко встановленої коректності, ніж про евристичну «захист», яку ви додаєте зовні. Я дивлюся на сторонні "плагіни безпеки" скептично. Коли сайт робить саме те, що я хочу, і лише це, він (за визначенням) захищений.
Джон Ватт

3

Це, мабуть, насправді не атака, а сканування або зонд.

Залежно від сканера / зонда, це може бути доброякісним, це означає, що він просто шукає проблеми в якомусь дослідницькому потенціалі, або він може мати функцію автоматичної атаки, якщо виявить отвір.

Веб-браузери містять дійсну інформацію про реферала, але інші програми можуть складати будь-який референт, який їм подобається.

Довідник - це просто інформація, яку необов'язково надають програми, що мають доступ до вашого веб-сайту. Це може бути все, що вони вирішили встановити на таке, як totally.meабо random.yu. Це може бути навіть справжній веб-сайт, який вони тільки що вибрали.

Ви дійсно не можете це виправити чи запобігти. Якщо ви намагалися заблокувати кожен запит цього типу, вам доведеться підтримувати дуже великий список, і це не варто.

Поки ваш хост не відстає від виправлень та запобігання вразливості, це не повинно створювати у вас ніяких проблем.


1
Якщо 404-и з'являються в Google WMT, це десь із реального посилання. total.me - це справжній сайт.
closetnoc

так total.me - це справжній сайт, і деякі помилкові посилання, що надходять звідти, були моєю провиною (помилки друку в кнопці твіт). Тепер ця маса посилається на viewtopic.php /? Будь-яку сторінку на моєму сайті, яку я клянусь, ніколи там не було. Я навіть можу визначити користувача, який це написав (на цій сторінці зараз нічого немає, але я припускаю, що було багато). У трендових тегах теж була навмисно неправильна URL-адреса. Що мене хвилює - це досвід користувачів, використання ресурсів і бачення того, що Google сканує ті підроблені 404. З іншого боку, я не можу заборонити всьому світу за не знайдену сторінку. Не впевнений, що робити.
таттвамасі

3

Дійсно це звучить як бот-шаленство. Нас також забивають тисячі IP-адрес у багатьох хостів, швидше за все, невідомих для сайту OP. Перш ніж я запропоную корисні рішення, одне запитання, яке у мене є:

З: Як ви бачите 404 з вашого сайту в цілому в інструментах Google для веб-майстрів? GWT - це вихід результатів Googlebots, а не вихід інших ботів. Крім того, ті інші боти не запускають JS для аналітики ... чи є у вас якась API API, яка переходить до GWT, де ви можете бачити статистику свого сервера? Якщо ні, то це може стати причиною тривоги, оскільки саме Google шукає помилки.

  • Якщо це ПОСЛІДні помилки googlebot, це може вказувати на те, що хтось посадив посилання на ваш сайт на форумах і про те, що на нього потрапляють цілі зловмисних ботів реальних людей-ПК Подумайте, що харвертор + плантатор працює на деякому експлуатованому сервері, встановлюючи безліч цілей для майбутніх "контрактів зі спамом" для проходження порталу.

  • Якщо ви дійсно знаєте, що його звітування про повну статистику сервера, вам знадобляться деякі інструменти. Кілька додатків та служб можуть допомогти вам їх зменшити. Якщо припустимо, що ви використовуєте Linux-сервер:

1) Почніть додавати неприйнятні IP-адреси в чорний список htaccess. Це виглядає як "заперечувати з 192.168.1.1" і 403 заборонить їх забороняти. Не захоплюйтесь просто блокуйте біггенів. Перевірте їх на сайтах на кроці 4), щоб переконатися, що вони не справжні Інтернет-провайдери. Ви можете скопіювати цей файл і наклеїти його на будь-який обліковий запис / додаток поза межами брандмауера.

2) Встановіть APF. справжнє просте управління брандмауером через SSH в Linux. Коли ви будуєте ht, додайте їх у APF на зразок "apf -d 192.168.1.1". Ht здається зайвим через APF, але Ht є портативним.

3) Встановіть cPanel Hulk і переконайтеся, що ваш білий IP-код не включений, щоб він не заблокував вас, якщо ви забудете пропуск. Це також буде чудовим джерелом IP-адрес, які потрібно додати до ht + apf. Це має певний розум, щоб він міг пом'якшити грубі спроби входу.

4) Підключіться до stopforumspam.com та projecthoneypot.org і запускайте їх модулі. Обидва допомагають відмовити у відомих запитах та виявити + повідомити про нові груби / сітки / чинаспам. Є фільтри електронної пошти, які ви також можете використовувати, але gmail є ним, коли справа доходить до фільтра спаму.

5) Оскільки боти ніколи не відступають, захистіть адміністраторські шляхи. Якщо ви запустите wordpress, змініть шлях адміністратора, додайте капчу та ін. Якщо ви використовуєте SSH, змініть порт входу на щось, що не використовується, а потім вимкніть кореневий вхід SSH. Створіть "radmin", ви повинні спочатку увійти, а потім su для root.

  • Зауваження про captcha, якщо ви запускаєте власну капчу на високому веб-сайті і не заперечуєте боту-шаленство на рівні брандмауера / ht, вони можуть забивати ваші цикли процесора завдяки генеруванню зображень у всіх цих віджетах "антиспам".

  • Примітка про навантаження, якщо ви запускаєте CentOS на своєму сервері та маєте здібності VPS, CloudLinux є фантастичним для загартування та контролю навантаження. Скажімо, бот проходить через CageFS, щоб обмежити його на рахунок. Скажіть, що вони вирішили DDoS .... LVE є для того, щоб утримувати обмеження завантаження облікового запису (сайту), щоб не зламати ваш сервер. Це добре доповнить акцент усієї системи "неумисного управління сутністю" :)

Просто деякі думки, я сподіваюся, що вам це допоможе


Спасибі. Те, що я бачу ці помилки у веб-майстрах Google, змушує задуматися - як ви правильно зазначаєте, - що існує якась техніка "NSEO" (посадка сотень посилань на мій сайт, які ніколи там не були). Сайт безпечний, оскільки такі види атак нічого не роблять. Я не впевнений, що я в безпеці для SEO / користувальницької роботи (якщо Google починає індексувати неіснуючі сторінки, я переживаю проблеми. Помилки вже зробили сайт падіння в рейтингу, btw). Знову дякую.
таттвамасі

1
Індекс Gbot не буде індексувати 404 сторінки, так що це дійсно не вплине на вашу SEO. Він може кешувати інші сторінки, що надсилають трафік, але не ваш. Якщо це стає проблемою для справжніх людей, зробіть величезний переспрямовувач для двоярусних посилань, таких як wp-admin, змусьте їх усіх приземлитись у приємному записі для людей про те, чому вони можуть бачити цю сторінку. Надайте їм купон "їм шкода за 404", якщо ти електронний. Просто не забудьте позначити їх усі як зафіксовані в GWT, щоб він індексував + кеш-пам'ять вашого нового навантажувача. Необов’язково покладіть на нього чорний отвір для значків. Незалежно, будьте готові до прямих звернень, якщо ця спам-мережа має для вас посилання.
dhaupin

Спасибі. Наразі я намагаюся побачити, чи м'який 404 у разі виникнення помилок трохи пом'якшує безлад. Сторінка 404 - це вже спеціальна сторінка, і вона надасть корисні пов’язані посилання (якщо вона може їх знайти). У разі неправильного написання мною я перекидаю переспрямування 301 на правильну сторінку (Google вважає їх м'якими 404, я думаю). У разі цього барахла /RK=0/RS=YkUQ9t4mR3PP_qt7IW8Y2L36PFo-/, /blog/wp-login.php/, /user/create_form/, /m/, /RK=0/RS=lznPhspsSDFHMiuIUDmmo01LA7w-/( і т.д. ...) Я вході користувача і повернення 404. Сподіваюся , що я роблю це правильно
tattvamasi

1

Пояснення проблеми

По-перше, ви не єдиний, хто має цю проблему - всі є. Що ви бачили, це результат автоматизованих ботів, які сканують кожен IP та шукають загальні вразливості. Тому вони в основному намагаються знайти те, що ви використовуєте, і якщо ви використовуєте phpmyadmin, вони згодом спробують створити купу стандартних комбінацій паролів.

Я здивований, що подібного роду ви знайшли саме зараз (можливо, ви тільки запустили свій сервер). Проблема полягає в тому, що ви не можете назавжди заблокувати їх IP-адресу (швидше за все, це заражений комп'ютер, і його фактичний користувач не знає, що він робить, також таких IP-адрес дуже багато).

Ефект SEO

Це взагалі не має ефекту. Це просто означає, що хтось намагався отримати доступ до чогось на вашому комп’ютері, а його там не було

Це насправді має значення?

Звичайно, ці люди намагаються перевірити вас на деякі проблеми. Більше того, вони витрачають ваші ресурси (ваш сервер повинен певним чином реагувати) та полірують ваш файл журналу

Як я можу це виправити

У мене була така ж проблема, яку я намагався виправити, і найкращий інструмент (простота у використанні проти того, що я можу зробити з цим) я зміг знайти - fail2ban

Вам також пощастило, тому що я вже знайшов спосіб виправити ту саму проблему і навіть задокументував її тут (тому вам не потрібно шукати, як її встановити та як змусити її працювати). Перевірте моє запитання на ServerFault . Але, будь ласка, прочитайте трохи про fail2ban, щоб знати, як це працює.


1

Як і багато хто з них вже говорили, це не атака, а спроба зондування або сканування програми вашого сайту та / або можливостей вашого сервера. Найкращий спосіб відфільтрувати весь цей марний трафік та потенційно небезпечні сканування - це застосувати WAF (брандмауер веб-додатків). Це дозволить зафіксувати всі різні спроби та позначити їх, і лише потім надішле справжній законний чистий трафік на ваші сервери та веб-додаток.

Ви можете використовувати хмарний DNS WAF або спеціальні пристрої. Я особисто використовую Incapsula та F5 ASM для різних клієнтських сайтів. Витрати становлять лише 500 доларів на місяць і надзвичайно допомагають. Це також забезпечує кращий захист ваших клієнтів та зменшує ресурси на самих веб-серверах, що заощадить ваші гроші та підвищить швидкість, плюс ці пристрої пропонують відповідність PCI 6.6 та огляди звітів.

Сподіваюсь, це допомагає.


Якщо це була просто "спроба зондування", то як ви пояснюєте той факт, що про ці 404 роки, мабуть, повідомили в GWT?
MrWhite
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.