Калі перанакіраванне WordPress становіцца ўразлівасцю, якая забівае сервер
Я гадамі аптымізаваў WordPress сайты, цюнінг MySQL, выпраўляючы канфігурацыі сервераў і выяўляючы праблемы з прадукцыйнасцю. Але нішто не падрыхтавала мяне да адкрыцця, якое я зрабіў, калі мой уласны сервер пачаў плавіцца пад нястомным кантролем CPU загрузка за апошні месяц. Гэта не быў рэзкі рэзкі рост трафіку. Гэта не быў збой убудовы. Гэта нават не быў дрэнны запыт у звычайным сэнсе. Сапраўднай віной аказалася тое, чаго я ніколі не чакаў: спосаб, якім WordPress перанакіроўвае супадзенні кэша убудовы.
На першы погляд, кэшаванне вынікаў перанакіраванняў здаецца разумным. Калі плагін перанакіравання выяўляе супадзенне з шаблонам, навошта пераацэньваць яго для таго ж шляху? Пры дакладных адзін-да-адназначных перанакіраваннях такая паводзіна бясшкодная — нават карысная. Але калі сайт падвяргаецца атацы, і вы ўмешваецеся ў гэта... LIKE або перанакіраванняў у стылі рэгулярных выразаў, кэш перанакіраванняў становіцца настолькі сур'ёзнай праблемай, што можа незаўважна знішчыць рэсурсы вашага сервера.
Гэта гісторыя пра тое, як я выявіў гэтую ўразлівасць, адсочваючы праблемы з прадукцыйнасцю ад рэзкіх скачкоў нагрузкі на працэсар да насычэння MySQL, а затым глыбей да росту табліц, які цалкам выйшаў з-пад кантролю.
Пачатак краху
Мой сервер працаваў хутчэй, чым калі-небудзь, з моманту міграцыі на FlyWPтаму раптоўнае павелічэнне спажывання працэсара выклікала занепакоенасць. MySQL паслядоўна ацэньваўся як высоказагружаны, PHP Работнікі стаялі ў чарзе, і нават простая загрузка старонак была павольнай. Перазапуск сервера даў мне кароткі перыяд стабільнасці, але праз некалькі гадзін, усё зноў бы дэградавала.
Нешта было ў корані не так.
Я ўключыў поўнае рэгістраванне запытаў, чакаючы знайсці дарагія злучэнні або неіндэксаваныя пошукі. Замест гэтага з'явілася дзіўная заканамернасць. Вялікая колькасць запытаў трапляла ў табліцу кэша перанакіраванняў, створаную плагінамі перанакіравання WordPress. Спачатку гэта мяне не насцярожыла — кэшаванне супадзенняў перанакіравання — распаўсюджаны метад паскарэння будучых запытаў. Але колькасць кэшаваных запісаў значна перавышала ўсё, што мог апраўдаць звычайны трафік.
Гэта завяло мяне ў трусіную нару.
Адсочванне праблемы ў MySQL
Табліца кэша перанакіраванняў рэзка павялічвалася ў памерах. Кожны раз, калі я правяраў, у ёй было на тысячы больш радкоў. Пры больш уважлівым разглядзе стала зразумела, чаму: кожны раз, калі URL трапляў на сервер, і любое правіла перанакіравання выкарыстоўвала частковае супадзенне—LIKE параўнанні, шаблоны падстаноўных знакаў або рэгулярныя выразы — плагін рэгістраваў вынік як зусім новы запіс у кэшы.
Хакеры і пошукавыя робаты спрабавалі ўзламаць не некалькі URL-адрасоў. Яны знаходзілі тысячы варыянтаў па ўсім сайце:
/random-path
/random-path1
/random-path2
/admin-old
/admin-new
/login-old
/login-backupКожны з гэтых шляхоў выклікаў новую ацэнку перанакіравання. З улікам перанакіраванняў на аснове шаблонаў, плагіну даводзілася выконваць дарагія параўнанні са сваімі правіламі перанакіравання. А паколькі ён кэшаваў кожнае супадзенне, табліца расла з кожным запытам, зробленым ботамі, сканерамі і інструментамі грубай сілы.
Чым большай станавілася табліца, тым даражэйшым станавілася кожнае параўнанне. MySQL не меў ніякіх шанцаў паспяваць за ім. Сервер не быў перагружаны легітымным трафікам. Яго перагружалі выдаткі на кіраванне шаблонамі перанакіраванняў.
Схаваная небяспека перанакіраванняў на аснове шаблонаў
Усе плагіны перанакіравання для WordPress абяцаюць гнуткае супастаўленне:
- Перанакіроўваць усё, што пачынаецца з пэўнага шляху
- Перанакіроўваць усё, што заканчваецца пэўнай структурай
- Шаблоны перанакіравання з выкарыстаннем падстаноўных сімвалаў
- Перанакіраванне з выкарыстаннем поўнага regex падтрымка
Гэтыя функцыі магутныя ў тэорыі і бяспечныя на невялікіх сайтах. Небяспека ўзнікае толькі тады, калі кэшаванне перанакіраванняў і супастаўленне з шаблонам сутыкаюцца ў вялікіх маштабах.
Кэшаванне здаецца добрай практыкай — і з дакладнымі перанакіраваннямі гэта так. Але калі LIKE Калі задзейнічаны аператары або шаблоны рэгулярных выразаў, кэшаванне становіцца бомбай запаволенага дзеяння. Спалучэнне складанай логікі пошуку, бесперапыннага супастаўлення і неабмежаванага росту кэша азначае, што рашучаму хакеру нават не трэба спецыяльна выбіраць перанакіраванні. Зондуе шляхі на вашым сайце дастаткова, каб паралізаваць ваш сервер.
Па меры таго, як правяраецца больш URL-адрасоў, ствараецца больш радкоў кэша. Па меры стварэння большай колькасці радкоў кожнае новае параўнанне становіцца павольнейшым. Па меры запаволення параўнанняў загрузка працэсара рэзка ўзрастае. У рэшце рэшт MySQL перагружаецца, патокі PHP спыняюцца, і ўся архітэктура пачынае збочваць.
Гэта не недахоп аднаго плагіна. Вось як працуюць універсальныя плагіны перанакіравання WordPress, калі ўключана складанае супастаўленне.
Пошук першапрычыны
Пасля таго, як я суаднеў нагрузку запытаў з актыўнасцю кэшавання перанакіраванняў, я непасрэдна праверыў табліцу кэша. Яна вырасла настолькі, што нават базавыя аперацыі былі павольнымі. Было нярэдка бачыць, як тысячы радкоў дадаюцца за кароткі прамежак часу. Кожны сканер, поўзальнік і бот, якія траплялі на непрадказальныя шляхі, дадаваў усё больш запісаў.
На гэтым этапе ўразлівасць стала відавочнай: плагіны перанакіравання WordPress міжволі дазваляюць зламыснікам несці экспанентныя выдаткі, праглядаючы вялікую колькасць URL-адрасоў. Ім не патрэбныя сапраўдныя шляхі. Ім не трэба ўзломваць сістэму. Ім трэба толькі прымусіць логіку перанакіравання працаваць.
Астатняе зрабіла сістэма перанакіравання.
Fix
Як толькі я зразумеў механіку, рашэнне з'явілася хутка. Нягледзячы на тое, што назва табліцы адрозніваецца ў залежнасці ад плагіна, кожны плагін перанакіравання падтрымлівае падобны кэш. У гэтым выпадку я выкарыстоўваю Ранг матэматыкі для маіх прыкладаў ніжэй:
- Выдаліце ўсе перанакіраванні LIKE і ў стылі рэгулярных выразаўЛюбое правіла перанакіравання, якое выкарыстоўвала супастаўленне на аснове шаблонаў, павінна было быць адключана. Актыўнымі маглі заставацца толькі дакладныя адзін-да-адназначныя перанакіраванні. Паколькі адміністратар быў адаптыўным, мне давялося зрабіць гэта праз запыт UPDATE непасрэдна ў маёй базе дадзеных.
UPDATE wp_rank_math_redirections
SET status = 'inactive'
WHERE sources NOT LIKE '%"comparison":"exact"%';- Скараціць табліцу кэша перанакіраванняўАчыстка табліцы прыбрала велізарны чэк па захаваных супадзеннях:
TRUNCATE TABLE wp_rank_math_redirections_cache;- Маніторынг сервера пасля ачысткіНагрузка на працэсар знізілася амаль імгненна. MySQL стабілізавалася. PHP-працэсары аднавілі нармальную працу. Імклівы рост спыніўся.
Дакладныя перанакіраванні працавалі менавіта так, як чакалася. Без перанакіраванняў з выкарыстаннем падстаноўных сімвалаў або рэгулярных выразаў ніякія атакі не маглі прымусіць кэш павялічыцца.
Што гэта азначае для карыстальнікаў WordPress
Плагіны перанакіравання WordPress не з'яўляюцца небяспечнымі ў традыцыйным сэнсе. Але яны маюць агульную архітэктурную ўразлівасць: кэшаванне вынікаў перанакіравання карысна толькі тады, калі гэтыя перанакіраванні дакладныя. Пасля ўвядзення супастаўлення з шаблонам кэшаванне становіцца небяспечным, таму што кожны невядомы URL становіцца новым запісам у кэшы.
На сайце з высокай наведвальнасцю або часта сканаваным сайтам гэта азначае:
- Рост табліцы становіцца неабмежаваным
- MySQL перагружаны
- Спіралі выкарыстання працэсара
- Сервер запавольваецца або выходзіць з ладу
Найлепшая абарона простая:
- Ніколі не спадзявайцеся на перанакіраванне з дапамогай падстаноўных сімвалаў або рэгулярных выразаў у WordPress
- Па магчымасці захоўвайце дакладную логіку перанакіравання
- Адпраўка складаных правілаў перанакіравання на NGINX або памежны ўзровень CDN
- Перыядычна правярайце або ачышчайце табліцы кэша перанакіраванняў
Кэшаванне перанакіраванняў карысна пры выкарыстанні з простымі, дакладнымі правіламі. Але як толькі сайт падвяргаецца аўтаматычнаму зондаванню і ў вас ёсць перанакіраванні на аснове шаблонаў, той жа механізм кэшавання становіцца праблемай, якая можа знізіць прадукцыйнасць сервера.
Я зразумеў гэта на ўласным горкім вопыце. Спадзяюся, гэта дапаможа камусьці пазбегнуць такой жа пасткі.
