A WordPress telepítéseiben az öt legfontosabb biztonsági hiányosság

A WordPress telepítése olyan biztonságos vagy bizonytalan lehet, amennyit csak akar. Tudja meg, mely öt dolog a legfontosabb a biztonság szempontjából.


A WordPress biztonságával kapcsolatos aggodalmak és panaszok semmi új.

Ha CMS-re van szüksége, és egy olyan szolgáltatóval konzultál, amely nem tartozik a WordPress-be, akkor a biztonság az első számú esemény, amellyel kapcsolatban hallani fogsz. Ez azt jelenti, hogy mindenkinek el kell dobnia a WordPress-t, és át kell állnia statikus webhely-generátorokra vagy fej nélküli CMS-re?

Nem, mert ugyanúgy, mint az élet minden igazságának, ennek is sok oldala van.

A WordPress nagyon bizonytalan?

Vessen egy pillantást néhány hatalmas webhelyre, amelyek a WordPress-en épültek:

  • TechCrunch
  • A New Yorker
  • BBC America
  • Bloomberg
  • MTV News
  • PlayStation Blog

Tehát mi teszi ezeket a vállalatokat – abszurd módon mély zsebükkel és gondolkodást okozó munkaerővel – nem a WordPressből való váltáshoz? Ha úgy gondolja, hogy a válasz örökölt kód, gondoljon újra: ezekre a nevekre az adatbiztonság és a nyilvános kép végtelenül fontosabb, mint egy egyszerű migráció, amely (becslésem szerint) kevesebb, mint 200 000 dollárba kerül..

Mérnökeik biztosan tudják, mit csinálnak, és nem látnak alapvető, megoldhatatlan biztonsági problémákat a WordPress használatával?

Még nekem is szerencsém van egy olyan WordPress telepítés kezelésére, amely havonta 3,5-4 millió látogatót lát. A biztonsági megsértések száma az elmúlt nyolc évben? Nulla!

Így . . . a WordPress biztonságos?

Sajnálom, ha úgy tűnik, hogy trolling, de itt van a válaszom:

Azt mondom, mert az élet minden igazságához hasonlóan bonyolult. Ahhoz, hogy legitim választ kapjunk, először meg kell értenünk, hogy a WordPress (vagy ebben az értelemben bármilyen előre beépített CMS) nem olyan, mint egy szekrény, amelyet állandóan valahol ragasztunk, és meg kell csinálni vele..

Ez egy komplex szoftver, sok függőséggel:

  • A PHP, amely nyelven készül
  • A nyilvánosan látható gép, amely a telepítést tárolja
  • A látogatók kezelésére használt webszerver (Apache, Nginx stb.)
  • A használt adatbázis (MySQL / MariaDB)
  • Témák (PHP, CS és JS fájlok csomagjai)
  • Beépülő modulok (PHP, CS és JS fájlok csomagjai)
  • És még sok más, attól függően, hogy a telepítést mennyire kívánja elérni

Más szavakkal, a biztonsági rés ezen varratok bármelyikén WordPress megsértésnek nevezik.

Ha a kiszolgáló gyökérjelszava admin123 volt, és veszélybe került, akkor a WordPress biztonsági hibája?

Ha a PHP verziója biztonsági rést okozott; vagy ha a megvásárolt és telepített új plugin egy átlátható biztonsági nyílást tartalmazott; stb. Összefoglalva: Egy alrendszer meghibásodik, és ez egy WordPress biztonsági hiba.

Mellett, kérjük, ne hagyja, hogy ez azt a benyomást keltje Önnek is, hogy a PHP, a MySQL és az Apache nem biztonságos. Minden szoftvernek vannak sebezhetőségei, amelyek száma megdöbbentő nyílt forráskód esetén (mert mindenki számára elérhető és megtekinthető és elemezhető).

Mondta valaki „biztonságosnak”? ��

Ezen adatok forrása és más demoralizáló statisztikák, ezt nézd meg.

Amit ebből a gyakorlatból megtanulunk:

Semmi sem biztonságos vagy nem biztonságos. A felhasznált különféle alkotóelemek képezik a láncszemeit, a lánc természetesen annyira erős, mint a leggyengébb. A WordPress „nem biztonságos” címkéje a régi PHP verziók, a megosztott tárhely és a nem megbízható forrásokból származó bővítmények / témák kombinációja.

Ugyanakkor néhány nagyon gyakori megfigyelés miatt a WordPress telepítése kiszolgáltatott lehet azok számára, akik tudják, hogyan kell kihasználni őket, és eltökélt. És erről szól ez a bejegyzés. Tehát további beavatkozás nélkül (és körkörös érvek nélkül) kezdjük el.

A WordPress legfontosabb kiskapuk, amelyeket a hackerek kihasználhatnak

A WordPress tábla előtagja

A híres 5 perces telepítés a legjobb dolog, ami történhet a WordPress-rel, de mint minden telepítővarázsló, lustossá tesz és alapértelmezésként hagyja a dolgokat.

Ez azt jelenti, hogy a WordPress táblázatok alapértelmezett előtagja a wp_, és olyan táblaneveket eredményez, amelyeket bárki kitalálhat:

  • wp-felhasználók
  • wp-opciók
  • wp-üzenete

Most fontolja meg az SQL Injection néven ismert támadást, ahol a rosszindulatú adatbázis-lekérdezéseket ügyesen illesztik be és futtatják a WordPressen belül (kérjük, vegye figyelembe – ez egyáltalán nem a WordPress / PHP-t kivételes támadás).

Noha a WordPress beépített mechanizmusokkal rendelkezik az ilyen típusú támadások kezelésére, senki sem garantálja, hogy nem fog megtörténni.

Tehát ha valamilyen módon, a támadónak sikerül olyan lekérdezést futtatnia, mint a DROP TABLE wp_users; DROP TABLE wp_posts ;, az összes fiókod, profilod és hozzászólásod egy pillanat alatt törlődik, anélkül hogy helyreállna (hacsak nincs biztonsági mentési rendszered, de még akkor is el kell veszítenie az adatokat az utolsó biztonsági másolat óta) ).

Az előtag egyszerűen a telepítés során történő megváltoztatása nagy ügy (ami szükséges nulla erőfeszítés).

Valami véletlenszerű, például az sdg21g34_ ajánlott, mert értelmetlen és nehéz kitalálni (minél hosszabb az előtag, annál jobb). A legjobb az, hogy ennek az előtagnak nem kell emlékezetesnek lennie; az előtagot a WordPress megmenti, és soha többé nem kell aggódnia (csakúgy, mint az alapértelmezett wp_ előtag miatt!).

Az alapértelmezett bejelentkezési URL

Honnan tudja, hogy egy webhely fut a WordPressen? Az egyik figyelmeztető jelzés az, hogy a WordPress bejelentkezési oldalát látja, amikor a /wp-login.php címet hozzáadja a webhely címéhez..

Példaként vegyük fel webhelyem (http://ankushthakur.com). A WordPressen van? Nos, add tovább, és add hozzá a bejelentkezési részt. Ha túl lusta érzi magát, a következő történik:

¯ \ _ (ツ) _ / ¯

WordPress, igaz?

Miután ezt sokkal megtudták, a támadó megdörzsölheti a kezét, és csúnya trükköket alkalmazhat a Bag-O’-Doomból ábécé alapon. Szegény én!

A megoldás az alapértelmezett bejelentkezési URL megváltoztatása, és csak azoknak adható meg, akikben megbíznak.

Például ez a webhely a WordPress-en is található, de ha meglátogatja a http://geekflare.com/wp-login.php webhelyet, akkor csak mély, mély csalódást okoz. A bejelentkezési URL rejtett, és csak az adminisztrátorok tudják ?.

A bejelentkezési URL megváltoztatása szintén nem rakéta tudomány. Csak fogd ezt csatlakoztat.

Gratulálunk, éppen hozzáadott egy újabb frusztráló biztonsági réteget a brutális erőszakos támadások ellen.

A PHP és a webszerver verziója

Már beszéltünk arról, hogy a szoftver, amelyet valaha írtunk (és írunk) tele van hibákkal, amelyek felhasználásra várnak.

Ugyanez vonatkozik a PHP-re.

Még akkor is, ha a PHP legújabb verzióját használja, nem lehet biztos benne, hogy vannak-e sebezhető pontok, és egyik napról a másikra felfedezhetők. A megoldás az, hogy elrejtse egy adott fejlécet, amelyet a webszerver küldött (soha nem hallottál a fejlécekről? Olvassa el ez!), amikor egy böngésző csatlakozik vele: x-powered-by.

Így néz ki, ha megnézi a kedvenc böngésző fejlesztőeszközeit:

Mint itt láthatjuk, a webhely azt mondja nekünk, hogy az Apache 2.4-en fut, és a PHP 5.4.16 verzióját használja..

Ez már egy csomó információ, amelyet ok nélkül átadunk, és segít a támadónak szűkíteni az eszközválasztékot.

Ezeket a (és hasonló) fejléceket el kell rejteni.

Szerencsére gyorsan meg lehet tenni; sajnos kifinomult műszaki ismeretekre van szükség, mivel bele kell merülnie a rendszer belsejébe, és össze kell kevernie a fontos fájlokat. Ezért azt tanácsolom, hogy kérje meg webhely-szolgáltatót, hogy tegye meg ezt érted; ha nem látják, meg tudja-e csinálni egy tanácsadó, bár ez nagymértékben függ az Ön webhelyének házigazdájától, függetlenül attól, hogy beállítottak-e ilyen lehetőségeket vagy sem.

Ha ez nem működik, akkor ideje lehet váltani a tárhelyszolgáltatókat, vagy áttérni a VPS-re, és fel kell venni a tanácsadót biztonsági és adminisztrációs problémákra..

Megéri? Csak te tudod eldönteni. ��

Ja, és ha meg akarja oldani a biztonsági fejléceket, akkor itt találja meg a javítást!

A bejelentkezési kísérletek száma

A hackerek kézikönyvének egyik legrégebbi trükköje az úgynevezett Szótár Attack.

Az ötlet az, hogy nevetségesen nagy számú (ha lehetséges) millió kombinációt kipróbál egy jelszóval, ha egyikük sem sikerül. Mivel a számítógépek villámgyorsan mûködnek, az ilyen ostoba séma ésszerû és ésszerû idõn belül eredményt hozhat.

Az egyik általános (és rendkívül hatékony) védelem az volt, hogy késleltetést adjunk a hiba bemutatása előtt. Ez arra készteti a címzettet, hogy várjon, ami azt jelenti, hogy hackelő által alkalmazott szkript esetében túl sokáig tart a befejezés. Ez az oka annak, hogy a számítógép vagy a kedvenc alkalmazás kissé visszapattan, és azt mondja: “Hoppá, rossz jelszó!”.

A lényeg az, hogy korlátoznia kell a bejelentkezési kísérletek számát a WordPress webhelyén.

Egy meghatározott számú (mondjuk öt) próbálkozáson túl a fiókot zárolni kell, és csak a fióktulajdonos e-mailjén keresztül állítható helyre..

Szerencsére, ha ez megtörténik, akkor ez egy kifutópálya, ha találsz kedveset csatlakoztat.

HTTP vs. HTTPS

Sokkal fontosabb, mint gondolnád, az SSL tanúsítvány, amelyben a szállító csalta.

Ez nem csupán a jó hírnév eszköze, hogy egy zöld zár ikont jelenítsen meg a böngészőben, amely „Biztonságos” feliratot mutat; Inkább az SSL-tanúsítvány telepítése és az URL-eknek a „https” -re történő működtetésére való kényszerítése önmagában elegendő ahhoz, hogy a webhely nyitott könyvté váljon a rejtélyes tekercsben.

Ha nem érti, hogyan történik ez, kérjük, olvassa el a ember-közép támadás.

A számítógépről a szerverre áramló forgalom lehallgatásának másik módja a csomag-szippantás, amely az adatgyűjtés passzív formája, és nem is kell fájdalmat keltenie ahhoz, hogy a középpontba kerüljön..

Az olyan webhelyek esetében, amelyek egyszerű HTTP-n futnak, a hálózati forgalmat elfogó személy jelszavai és hitelkártya-számai tiszta, egyértelmű szövegként jelennek meg.

Forrás: Compareitech.com

Ijedős? Nagyon!

Miután telepítette az SSL-tanúsítványt, és az összes URL „https-re” konvertálódik, ez az érzékeny információ száguldásnak tűnik, amelyet csak a szerver tud dekódolni. Más szavakkal: ne izzadd meg azt a néhány dollárt évente. ��

Következtetés

Ezt az öt dolgot ellenőrzés alatt tartva szépen biztosítja webhelyét?

Nem, egyáltalán nem. Mint számtalan biztonsági cikk írja, soha nem vagy 100% -ban biztonságos, de ésszerű erőfeszítésekkel meg lehet szüntetni a problémák nagy osztályát. Fontolhatja a SUCURI felhő WAF használatát a webhelyek holisztikus védelme érdekében.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map