15%

Збережіть 15% на всі хостинг-послуги

Перевірте свої навички і отримайте Знижку на будь-який план хостингу

Використовуй код:

Skills
Почати
21.10.2024
12 +1

Трекбеки та пінгбеки у WordPress: що це таке, як вони працюють і чи варто їх використовувати

Trackbacks та pingbacks — це протоколи міжблогових сповіщень WordPress, які автоматично або вручну повідомляють вказаний веб-сайт, коли інший сайт посилається на його контент. Pingback повністю автоматизований — WordPress надсилає та перевіряє його без будь-якого втручання користувача. Trackback є напівручним — автор повинен вказати URL-адресу кінцевої точки trackback цільового блогу, а сповіщення містить короткий уривок із публікації, що посилається.

Обидва механізми були розроблені для створення децентралізованого рівня спілкування в ранній блогосфері. На практиці обидва стали основними векторами для спаму в коментарях, і більшість виробничих сайтів WordPress повністю вимикають їх. Розуміння того, як саме працює кожен протокол — і конкретних наслідків для безпеки та SEO від їх активного використання — є необхідним перед прийняттям цього рішення.

Технічна архітектура кожного протоколу

Як працюють Trackbacks зсередини

Trackback — це HTTP POST-запит, надісланий на конкретну URL-адресу trackback, яку надає цільовий блог. Корисне навантаження являє собою просте тіло у форматі form-encoded, що містить чотири поля: title, url, blog_name та excerpt. Сервер-одержувач аналізує ці поля і, якщо схвалює, відображає уривок як запис, схожий на коментар, у зазначеній публікації.

Протокол не має вбудованого кроку перевірки. Сервер-відправник не робить жодного криптографічного підтвердження щодо вмісту публікації з посиланням, а сервер-одержувач не має надійного способу підтвердити, що посилання дійсно існує. Цей архітектурний недолік є першопричиною спаму через trackback: будь-який скрипт може надіслати POST із сфабрикованими даними на кінцеву точку trackback, не публікуючи жодного реального посилання.

Необроблений trackback POST виглядає так:

curl -X POST https://example.com/wp-trackback.php?p=42 
  -d "title=My+Post+Title" 
  -d "url=https://attacker.com/fake-post" 
  -d "blog_name=Legitimate+Looking+Blog" 
  -d "excerpt=This+is+a+fabricated+excerpt."

Оскільки немає рукостискання, сервер-одержувач не може відрізнити це від законного сповіщення.

Як працюють Pingbacks зсередини

Pingbacks використовують XML-RPC як транспортний рівень, зокрема метод pingback.ping, визначений у специфікації Pingback 1.0. Коли ви публікуєте запис із зовнішнім посиланням, WordPress викликає pingback.ping на цільовому сервері, передаючи два аргументи: URL вашої публікації (джерело) та URL сторінки з посиланням (ціль).

Потім сервер-одержувач виконує критичний крок, який trackbacks повністю пропускають: він отримує вихідний URL і підтверджує, що посилання на ціль дійсно існує в HTML сторінки. Лише після цієї перевірки він записує pingback.

<?xml version="1.0"?>
<methodCall>
  <methodName>pingback.ping</methodName>
  <params>
    <param><value><string>https://yoursite.com/your-post/</string></value></param>
    <param><value><string>https://targetsite.com/their-post/</string></value></param>
  </params>
</methodCall>

Ця перевірка робить pingbacks складнішими для підробки, ніж trackbacks, але вона вводить іншу вразливість: Server-Side Request Forgery (SSRF). Зловмисник може створити pingback, який змушує цільовий сервер отримати довільний внутрішній URL — включаючи http://127.0.0.1/wp-admin/ або кінцеві точки метаданих хмари, як-от http://169.254.169.254/ — фактично використовуючи стек XML-RPC WordPress як проксі.

Trackbacks проти Pingbacks: порівняння пліч-о-пліч

ФункціяTrackbackPingback
ІніціаціяРучна (автор вставляє URL кінцевої точки)Автоматична (запускається при публікації)
Транспортний протоколHTTP POST (form-encoded)XML-RPC (`pingback.ping`)
Перевірка посиланняВідсутняТак — сервер отримує вихідний URL
Містить уривокТакНі (лише посилання)
Стійкість до спамуДуже низькаНизька (натомість ризик SSRF)
Обидва сайти повинні підтримуватиНіТак
Досі широко використовуєтьсяНіРідко
Основний ризик безпекиВпровадження підробленого контентуSSRF / DDoS-підсилення

Як увімкнути або вимкнути Trackbacks та Pingbacks у WordPress

Глобальне налаштування через панель керування

Найшвидший спосіб керувати обома протоколами на рівні всього сайту — через налаштування обговорення WordPress:

  1. Увійдіть до адміністративної панелі WordPress.
  2. Перейдіть до Налаштування > Обговорення.
  3. У розділі Стандартні налаштування статей знайдіть прапорець із позначкою «Дозволити сповіщення про посилання з інших блогів (pingbacks та trackbacks)».
  4. Зніміть прапорець, щоб вимкнути обидва протоколи глобально, а потім натисніть Зберегти зміни.

Це налаштування застосовується лише до публікацій, створених після внесення змін. Воно не вимикає pingbacks та trackbacks на вже існуючих публікаціях ретроактивно.

Керування для окремих публікацій

Щоб керувати сповіщеннями для конкретної публікації:

  1. Відкрийте публікацію в блоковому редакторі.
  2. На правій бічній панелі прокрутіть до панелі Обговорення. Якщо вона не відображається, відкрийте Параметри екрана (верхній правий кут) і увімкніть прапорець Обговорення.
  3. Зніміть прапорець Дозволити pingbacks та trackbacks.
  4. Оновіть або опублікуйте публікацію.

Масове вимкнення для всіх існуючих публікацій через SQL

Якщо ваш сайт має тисячі існуючих публікацій, підхід через панель керування є непрактичним. Виконайте наступний запит безпосередньо до вашої бази даних WordPress — завжди спочатку створюйте резервну копію:

UPDATE wp_posts
SET ping_status = 'closed'
WHERE post_status = 'publish'
  AND post_type = 'post';

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

Блокування кінцевої точки XML-RPC на рівні сервера

Вимкнення pingbacks у налаштуваннях WordPress все одно залишає кінцеву точку xmlrpc.php доступною. Для повного захисту заблокуйте її на рівні веб-сервера.

Apache — додайте до .htaccess або конфігурації вашого віртуального хосту:

<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

Nginx — додайте всередині вашого блоку server {}:

location = /xmlrpc.php {
    deny all;
    return 403;
}

Блокування xmlrpc.php також нейтралізує вектор атаки DDoS-підсилення на основі XML-RPC, коли зловмисники надсилають тисячі pingback-запитів на сайт WordPress, кожен із яких змушує сервер робити вихідні HTTP-запити — фактично перетворюючи ваш сервер на мимовільного учасника розподіленої атаки.

Якщо ви запускаєте WordPress на плані VPS Hosting, у вас є повний root-доступ для безпосереднього впровадження цих правил на рівні сервера. Спільні середовища можуть натомість вимагати .htaccess або плагіна безпеки.

Ризики безпеки, які не можна ігнорувати

DDoS-підсилення на основі Pingback

Оскільки pingback.ping змушує сервер-одержувач робити вихідний HTTP-запит, ботнет може надіслати десятки тисяч pingback-запитів на вразливий сайт WordPress, кожен із яких інструктує його отримати URL жертви. Сервер WordPress стає підсилювачем. Цей шаблон атаки був широко задокументований ще у 2014 році і залишається актуальним скрізь, де xmlrpc.php є відкритим.

SSRF через Pingback

На хмарних інсталяціях WordPress — включаючи ті, що працюють на VPS Hosting або Виділених серверах — зловмисник може надіслати pingback, де вихідний URL вказує на адресу внутрішньої мережі. Якщо сервер не захищений брандмауером на рівні гіпервізора або VPC, запит перевірки pingback може досягти:

  • http://127.0.0.1/wp-admin/ — зондування внутрішніх адміністративних інтерфейсів
  • http://169.254.169.254/latest/meta-data/ — метадані екземпляра AWS EC2
  • Внутрішніх кінцевих точок бази даних або кешу

Для пом’якшення цього потрібно як заблокувати xmlrpc.php, так і переконатися, що правила вихідного брандмауера вашого сервера запобігають запитам до діапазонів адрес RFC 1918 та link-local.

Спам через Trackback та забруднення коментарів

Оскільки trackbacks не мають перевірки, ними тривіально зловживають. Одна спам-кампанія може впровадити сотні фальшивих trackbacks у вашу чергу коментарів, кожен із яких посилається на сайти розповсюдження шкідливого програмного забезпечення, фармацевтичний спам або фішингові сторінки. Навіть із увімкненою модерацією, обсяг може перевантажити адміністраторів сайту та погіршити співвідношення сигнал/шум у законних коментарях.

Реальність SEO для Trackbacks та Pingbacks у 2024 році

Коли ці протоколи були розроблені на початку 2000-х років, будь-яке зворотне посилання мало значущий сигнал PageRank. Алгоритм Google з тих пір суттєво еволюціонував. Зараз застосовуються кілька реалій:

  • Самореференційні pingbacks (WordPress, що пінгує власні внутрішні посилання) генерують посилання в коментарях із тегом nofollow, які не несуть жодної цінності PageRank.
  • Посилання Trackback, що з’являються в розділах коментарів, майже повсюдно позначені nofollow у сучасних темах WordPress, тобто вони не передають жодного посилального капіталу.
  • Trackbacks, згенеровані спамом, якщо їх випадково схвалено, можуть пов’язати ваш домен із низькоякісними або покараними сайтами — що є чистим негативом для вашого профілю авторитетності.
  • Система Google SpamBrain ефективно виявляє та знецінює шаблони посилань, що походять із розділів коментарів, включаючи посилання, згенеровані через trackback.

Практична SEO-цінність увімкнення будь-якого з протоколів фактично дорівнює нулю для більшості сайтів. Ризик забруднення спамом та загроза безпеці — ні.

Коли Trackbacks та Pingbacks все ще мають законне використання

Існують вузькі сценарії, де ці функції зберігають цінність:

  • Закриті, приватні мережі блогів (інтранети, академічні видавничі платформи), де всі сайти-учасники є довіреними і спам не є проблемою.
  • Застарілі інтеграції CMS, де партнерська платформа підтримує лише pingback як механізм сповіщення і сучасна альтернатива на основі webhook недоступна.
  • Налагодження та дослідження протоколів — розуміння того, як працює потік pingback XML-RPC, є цінним при аудиті конфігурацій безпеки WordPress.

Поза цими контекстами функції слід вимкнути.

Налаштування обговорення WordPress та найкращі практики модерації коментарів

Якщо ви вирішите залишити pingbacks увімкненими — наприклад, щоб відстежувати, коли інші довірені сайти у вашій мережі посилаються на ваш контент — впровадьте такі засоби контролю:

  • Увімкніть Модерацію коментарів, щоб жоден pingback не з’являвся публічно без ручного схвалення (Налаштування > Обговорення > Перед появою коментаря > Коментар повинен бути схвалений вручну).
  • Додайте відомі спам-домени до списку Заборонених ключових слів коментарів у розділі Налаштування > Обговорення.
  • Встановіть плагін фільтрації спаму (Akismet є найбільш широко розгорнутим), щоб автоматично позначати спам trackback та pingback до того, як він потрапить до вашої черги модерації.
  • Регулярно перевіряйте чергу коментарів. Схвалені спам-trackbacks складніше очистити ретроактивно, ніж заблоковані.

Для сайтів, що працюють у керованих середовищах WordPress або на VPS з cPanel, правила ModSecurity в cPanel можуть додати додатковий рівень фільтрації проти неправильно сформованих XML-RPC-запитів до того, як вони досягнуть рівня застосунку WordPress.

Практична матриця прийняття рішень

Використовуйте цей контрольний список, щоб визначити правильну конфігурацію для вашого сайту:

Вимкніть обидва — trackbacks та pingbacks — якщо:

  • Ваш сайт є публічно доступним і отримує будь-який обсяг органічного трафіку
  • У вас немає спеціального робочого процесу модерації коментарів
  • Ви запускаєте WordPress на спільному або хмарному сервері без блокування XML-RPC на рівні сервера
  • У вас немає встановлених відносин з іншими блогами, які покладаються на ці протоколи

Розгляньте можливість залишити pingbacks увімкненими лише якщо:

  • Усі сайти, що посилаються, відомі, довірені та знаходяться в контрольованій мережі
  • Модерація коментарів налаштована на ручне схвалення
  • xmlrpc.php захищений IP-allowlisting або HTTP-аутентифікацією на рівні сервера
  • Ви підтвердили, що ваше хостингове середовище не є вразливим до SSRF через вихідні HTTP-запити

Завжди виконуйте незалежно від вашого вибору:

  • Запустіть SQL-запит вище, щоб закрити статус ping для всіх існуючих публікацій
  • Заблокуйте xmlrpc.php на рівні веб-сервера, якщо ви не використовуєте XML-RPC для будь-яких інших цілей (REST API є сучасною заміною для мобільних застосунків та віддаленої публікації)
  • Перевірте існуючу чергу коментарів на наявність раніше схвалених спам-trackbacks

Для сайтів, яким потрібна надійна інфраструктура для впровадження цих засобів контролю на рівні сервера, Виділені сервери забезпечують повний доступ на рівні мережі та ОС, необхідний для застосування правил брандмауера, блокування конкретних кінцевих точок та моніторингу спроб вихідних з’єднань від процесу веб-сервера.

FAQ

Чи є trackbacks та pingbacks одним і тим самим?

Ні. Trackbacks — це ручні HTTP POST-сповіщення, які містять уривок і не виконують перевірку посилань. Pingbacks — це автоматизовані XML-RPC-виклики, які перевіряють, що публікація з посиланням дійсно містить вказаний URL, перш ніж записати сповіщення. Вони мають однакову мету, але використовують різні протоколи з різними профілями безпеки.

Чи допомагають trackbacks та pingbacks з SEO?

Не будь-яким значущим чином. Посилання, згенеровані цими механізмами, з’являються в розділах коментарів і за замовчуванням позначені nofollow у WordPress, тобто вони не передають PageRank. Trackbacks, згенеровані спамом, можуть активно шкодити авторитету вашого сайту, пов’язуючи його з низькоякісними доменами.

Чи можу я вимкнути pingbacks, не вимикаючи весь XML-RPC API?

Так. Ви можете вимкнути pingbacks конкретно через Налаштування > Обговорення або шляхом фільтрації хука xmlrpc_methods у WordPress для видалення pingback.ping та pingback.extensions.getPingbacks, залишаючи інші методи XML-RPC незмінними. Однак блокування xmlrpc.php повністю на рівні сервера є більш безпечним підходом, якщо у вас немає інших залежностей від XML-RPC.

Який ризик SSRF пов’язаний із pingbacks WordPress?

Коли сайт WordPress отримує pingback, він робить вихідний HTTP-запит до вихідного URL для перевірки посилання. Зловмисник може вказати внутрішню IP-адресу як вихідний URL, змушуючи сервер зондувати внутрішні мережеві ресурси. Це вразливість Server-Side Request Forgery. Блокування xmlrpc.php на рівні веб-сервера повністю усуває цю поверхню атаки.

Як масово закрити pingbacks для тисяч існуючих публікацій WordPress?

Використовуйте прямий SQL-запит до вашої бази даних WordPress: UPDATE wp_posts SET ping_status = 'closed' WHERE post_status = 'publish' AND post_type = 'post'; — завжди робіть резервну копію бази даних перед виконанням будь-яких прямих SQL-модифікацій. Налаштування панелі керування WordPress впливає лише на нові публікації в майбутньому.

15%

Збережіть 15% на всі хостинг-послуги

Перевірте свої навички і отримайте Знижку на будь-який план хостингу

Використовуй код:

Skills
Почати