Deaktiveer die inheemse soekfunksie in WordPress heeltemal om te verhoed dat kwaadwillige programme die databasis skandeer en laat ineenstort.

Heeltemal deaktiveer WordPress Die voorkant beskik oor 'n inheemse soekfunksie om te verhoed dat die databasis oorweldig word deur skandering.

Die databasis stort nie in duie nie omdat jou webwerf te veel inhoud het, maar omdat jy steeds daardie belaglik ondoeltreffende inheemse WordPress-soektog gebruik.

Baie webwerf-eienaars kyk een feit oor die hoof: die voorkant... ?s= Soekparameters is 'n gunsteling van hackers en skandeerders.

As iemand aanhou om versoeke aan die soekkoppelvlak te rig, sal jou databasis gedwing word om duisende betekenislose navrae uit te voer.

Die gevolg? Die SVE-gebruik het gestyg, geheueverbruik het ontplof en die webwerf het ineengestort.

Dit is nie 'n oordrywing nie, maar 'n werklike en pynlike ervaring van tallose webwerwe.

Waarom deaktiveer WordPress se inheemse soektog?

WordPress se ingeboude soekfunksie is in wese 'n volteks LIKE-navraag in die databasis.

Hierdie navraag is uiters ondoeltreffend, veral wanneer die aantal artikels 10 000 oorskry; 'n enkele soektog kan meer as 0.5 sekondes duur.

As iemand 'n webkruiper of aanvalskrip gebruik om dosyne soekversoeke per sekonde te stuur, sal jou databasis onmiddellik oorweldig word.

Volgens die amptelike WordPress-dokumentasie het inheemse soektog geen beskermingsmeganismes nie en is dit heeltemal blootgestel aan die voorkant. Dit beteken dat aanvallers hierdie toegangspunt kan misbruik sonder om eers aan te meld.

Alternatiewe oplossing: Koppel aan 'n slimmer soekenjin

Baie professionele webwerwe maak nie meer staat op WordPress se inheemse soektog nie.

Byvoorbeeld, toegang Google Programmeringsoektog of Algolia Sulke derdeparty-soekdienste is nie net vinnig nie, maar lewer ook meer akkurate resultate.

Boonop sal hierdie dienste nie jou databasis verlam nie, want alle navrae word ekstern uitgevoer.

So as jou webwerfPosisioneringAs dit 'n hulpmiddelwebwerf, 'n blogwebwerf of selfs 'n webwerf is wat reeds op eksterne soektog staatmaak, is daar geen rede om die ingeboude soekfunksie van WordPress te behou nie.

Deaktiveer WordPress front-end soekkode implementering heeltemal

Die mees direkte manier is om op die tema te fokus. functions.php Voeg die volgende kode by die lêer:

// 禁用 WordPress 前台搜索功能，防止被扫描拖垮数据库
function disable_wp_search( $query, $error = true ) {
    if ( is_search() && !is_admin() ) {
        $query->is_search = false;
        $query->query_vars['s'] = false;
        $query->query['s'] = false;
        if ( $error == true ) {
            // 直接返回 404 页面，不走任何数据库查询
            $query->set_404();
            status_header( 404 );
            nocache_headers();
        }
    }
}
add_action( 'parse_query', 'disable_wp_search' );
add_filter( 'get_search_form', '__return_empty_string' );

Die logika van hierdie kode is baie eenvoudig:

• Sodra 'n voorgrondsoekversoek bespeur word, word databasisnavrae onmiddellik geblokkeer.
• Om terug te keer na 'n 404-bladsy blokkeer die toegangspunt heeltemal.
• Terselfdertyd is die soekvorm verwyder om toevallige gebruikersaksies te voorkom.

Die voordeel van hierdie metode is dat selfs al maak 'n aanvaller talle versoeke... ?s=xxxDit sal geen databasisnavrae aktiveer nie.

'n Meer elegante implementering: die gebruik van Fluent Snippets

As jy nie die temalêers direk wil wysig nie, kan jy dit gebruik ... Vloeiende brokkies inprop.

Hierdie inprop laat jou toe om kodebrokkies direk in die agtergrond by te voeg, en om die effekte en wysigings te sien. functions.php Dieselfde, maar veiliger.

Sodra dit geaktiveer is, kan jy maklik al jou persoonlike kode bestuur sonder om bekommerd te wees dat tema-opdaterings dit oorskryf.

Werklike resultate: Databasisdruk het skerp gedaal.

In 'n konfigurasie van 2-kern SVE + 4 GB RAM Op die VPS, toe die inheemse soektog 50 versoeke per sekonde gemaak het, het die databasis se SVE-benutting tot 95% gestyg.

Nadat soektog gedeaktiveer is, het dieselfde versoek direk 'n 404-fout teruggegee, en die databasislading was amper nul.

Daarom beveel baie sekuriteitskenners sterk aan om WordPress se inheemse soektog onmiddellik af te skakel as jy dit nie nodig het nie.

Sekuriteitsnavorsers het eksplisiet in Sucuri se amptelike blog gesê:

"WordPress se inheemse soektog is een van die maklikste toegangspunte om te benut; aanvallers kan diensneigingsaanvalle skep deur gereelde soekversoeke te maak."

Hierdie stelling is voldoende om die probleem te verduidelik.

Ten slotte: Veiligheid is nie 'n opsie nie, maar 'n verpligte kursus.

Webwerfsekuriteit is nie net 'n bonus nie, dit is 'n kwessie van lewe en dood.

Om WordPress se inheemse soektog te deaktiveer, mag dalk soos 'n klein aksie lyk, maar dit kan jou databasis red van oorweldiging.

In hierdie era van inligtingoorlading lê ware wysheid nie in die byvoeging van funksies nie, maar in die beslissende verwerping van dié wat ondoeltreffend of gevaarlik is.

Onthou: Veiligheid is nie 'n koste nie, dis 'n waarde.

As jy nog steeds huiwer, vra jouself die volgende af: Wil jy liewer jou databasis laat ineenstort te midde van die gelag van aanvallers, of wil jy liewer beheer oor die situasie neem?