Вашата инсталация на WordPress може да бъде толкова сигурна или несигурна, колкото искате. Научете кои пет неща са най-важни, когато става въпрос за сигурност.
Притесненията и оплакванията относно сигурността на WordPress не са нищо ново.
Ако имате нужда от CMS и случайно се консултирате с доставчик на услуги, който не е в WordPress, сигурността е номер едно против, за който ще чуете. Това означава ли, че всеки трябва да се откаже от WordPress и да премине към статични генератори на сайтове или безглавна CMS?
Не, защото както всяка истина в живота и тази има много страни.
Съдържание
Много несигурен ли е WordPress?
Нека да разгледаме някои огромни уебсайтове, изградени на WordPress:
- TechCrunch
- The New Yorker
- Би Би Си Америка
- Блумбърг
- Новини на MTV
- Блог на PlayStation
И така, какво кара тези компании – с абсурдно дълбоки джобове и умопомрачителна работна сила – да не преминат от WordPress? Ако смятате, че отговорът е наследен код, помислете отново: за тези имена сигурността на данните и публичният имидж са безкрайно по-важни от проста миграция, която ще струва (преценявам) по-малко от $200 000.
Със сигурност техните инженери знаят какво правят и не виждат фундаментални, неразрешими проблеми със сигурността с WordPress?
Дори аз имам късмета да управлявам инсталация на WordPress, която вижда 3,5-4 милиона посетители на месец. Общият брой на пробиви в сигурността през последните осем години? Нула!
Така . . . защитен ли е WordPress?
Съжалявам, ако изглежда като тролене, но ето моят отговор:
Казвам го, защото като всяка истина в живота и тя е сложна. За да стигнем до легитимен отговор, първо трябва да разберем, че WordPress (или която и да е предварително изградена CMS, по този въпрос) не е като шкаф, който оставяте някъде за постоянно и свършвате с него.
Това е сложен софтуер с много зависимости:
- PHP, който е езикът, с който е изграден
- Публично видима машина, която хоства инсталацията
- Уеб сървърът, използван за обработка на посетители (Apache, Nginx и др.)
- Използваната база данни (MySQL/MariaDB)
- Теми (пакети от PHP, CS и JS файлове)
- Добавки (пакети от PHP, CS и JS файлове)
- И много други, в зависимост от това колко цели да постигне вашата инсталация
С други думи, пробив в сигурността на който и да е от тези шевове ще бъде наречен пробив в WordPress.
Ако основната парола на сървъра е admin123 и е била компрометирана, това ли е пропуск в сигурността на WordPress?
Ако версията на PHP е имала уязвимост в сигурността или ако новият плъгин, който сте закупили и инсталирали, съдържа очевидна дупка в сигурността; и така нататък. За да обобщим: подсистема се проваля и това е повреда в сигурността на WordPress.
Като настрана, моля, не позволявайте това да ви създаде впечатлението, че PHP, MySQL и Apache не са сигурни. Всяка част от софтуера има уязвимости, чийто брой е зашеметяващ в случая с отворен код (защото е достъпен за всеки да види и анализира).
Някой каза ли „сигурно“? 😛
Това, което научаваме от цялото това упражнение е следното:
Нищо не е сигурно или несигурно само по себе си. Използваните различни компоненти образуват връзките във веригата, като веригата, разбира се, е толкова силна, колкото и най-слабите от тях. В исторически план етикетът „не е защитен“ на WordPress е комбинация от стари PHP версии, споделен хостинг и добавяне на плъгини/теми от ненадеждни източници.
В същото време някои доста често срещани пропуски правят вашата WordPress инсталация уязвима за тези, които знаят как да ги използват и са решителни. И за това е тази публикация. Така че без повече шум (и кръгови аргументи), нека да започнем.
Топ вратички в WordPress, които хакерите могат да използват
Префиксът на таблицата на WordPress
Известното 5-минутно инсталиране е най-доброто нещо, което може да се случи на WordPress, но като всички съветници за инсталиране, това ни прави мързеливи и оставя нещата по подразбиране.
Това означава, че префиксът по подразбиране за вашите WordPress таблици е wp_, което води до имена на таблици, които всеки може да познае:
- wp-потребители
- wp-опции
- wp-постове
Сега помислете за атака, известна като SQL Injection, при която злонамерените заявки към базата данни се вмъкват умело и се изпълняват вътре в WordPress (моля, имайте предвид – това в никакъв случай не е атака, ексклузивна за WordPress/PHP).
Докато WordPress има вградени механизми за справяне с този тип атаки, никой не може да гарантира, че това няма да се случи.
Така че, ако по някакъв начин, по някакъв начин, атакуващият успее да изпълни заявка като DROP TABLE wp_users; DROP TABLE wp_posts;, всичките ви акаунти, профили и публикации ще бъдат изтрити за миг без шанс за възстановяване (освен ако нямате въведена схема за архивиране, но дори и тогава непременно ще загубите данни след последното архивиране ).
Простата промяна на префикса по време на инсталацията е голяма работа (която не изисква никакви усилия).
Нещо произволно като sdg21g34_ се препоръчва, защото е глупост и трудно за отгатване (колкото по-дълъг е префиксът, толкова по-добре). Най-добрата част е, че този префикс не трябва да бъде запомнящ се; префиксът е нещо, което WordPress ще запази и никога повече няма да се налага да се тревожите за него (точно както не се притеснявате за префикса wp_ по подразбиране!).
URL адресът за влизане по подразбиране
Как да разберете, че даден уебсайт работи на WordPress? Един от сигналните знаци е, че виждате страницата за вход в WordPress, когато добавите „/wp-login.php“ към адреса на уебсайта.
Като пример, нека вземем моя уебсайт (http://ankushthakur.com). На WordPress ли е? Е, продължете и добавете частта за влизане. Ако се чувствате твърде мързеливи, ето какво се случва:
¯_(ツ)_/¯
WordPress, нали?
След като стане известно това, нападателят може да потрие ръце от радост и да започне да прилага неприятни трикове от своя Bag-O’-Doom по азбучен ред. Горката аз!
Решението е да промените URL адреса за влизане по подразбиране и да го дадете само на онези хора, на които има доверие.
Например, този уебсайт също е на WordPress, но ако посетите http://pctechbg.net.com/wp-login.php, всичко, което ще получите, е дълбоко разочарование. URL адресът за вход е скрит и е известен само на администраторите?
Промяната на URL адреса за влизане също не е нова наука. Просто вземете това плъгин.
Поздравления, вие току-що добавихте още един слой разочароваща сигурност срещу атаки с груба сила.
Версията на PHP и уеб сървъра
Вече обсъдихме, че всеки софтуер, който някога е писан (и се пише) е пълен с грешки, чакащи да бъдат експлоатирани.
Същото важи и за PHP.
Дори ако използвате най-новата версия на PHP, не можете да сте сигурни какви уязвимости съществуват и може да бъдат открити за една нощ. Решението е да скриете конкретен хедър, изпратен от вашия уеб сървър (никога не сте чували за хедъри? прочетете това!), когато браузър се свърже с него: x-powered-by.
Ето как изглежда, ако проверите инструментите за разработка на любимия си браузър:
Както виждаме тук, уебсайтът ни казва, че работи на Apache 2.4 и използва PHP версия 5.4.16.
Това вече е много информация, която предаваме без причина, помагайки на нападателя да стесни избора си от инструменти.
Тези (и подобни) заглавки трябва да бъдат скрити.
За щастие, може да се направи бързо; за съжаление са необходими сложни технически познания, тъй като ще трябва да се потопите в вътрешностите на системата и да се забърквате с важни файлове. Ето защо, моят съвет е да помолите вашия доставчик на хостинг уебсайтове да направи това вместо вас; ако не видят дали консултант може да го направи, въпреки че това ще зависи до голяма степен от хоста на вашия уебсайт дали тяхната настройка има такива възможности или не.
Ако не работи, може би е време да смените доставчика на хостинг или да преминете към VPS и да наемете консултант за проблеми със сигурността и администрацията.
Струва ли си? Само вие можете да решите това. 🙂
О, и ако искате да маниакирате по заглавките за сигурност, ето вашето решение!
Брой опити за влизане
Един от най-старите трикове в наръчника на хакера е т.нар Речник Атака.
Идеята е да опитате абсурдно голям брой (милиони, ако е възможно) комбинации за парола, освен ако една от тях не успее. Тъй като компютрите са светкавично бързи в това, което правят, такава глупава схема е разумна и може да даде резултати за разумно време.
Една често срещана (и изключително ефективна) защита е добавянето на забавяне преди показване на грешката. Това кара получателя да чака, което означава, че ако това е скрипт, използван от хакер, ще отнеме твърде много време, за да завърши. Това е причината вашият компютър или любимо приложение да подскача малко и след това да каже: „Ами сега, грешната парола!“.
Както и да е, въпросът е, че трябва да ограничите броя на опитите за влизане във вашия WordPress сайт.
След определен брой опити (да речем пет), акаунтът трябва да се заключи и да може да бъде възстановен само чрез имейла на притежателя на акаунта.
За щастие, да направите това е лесно, ако попаднете на хубав плъгин.
HTTP срещу HTTPS
SSL сертификатът, за който вашият доставчик ви досажда, е по-важен, отколкото си мислите.
Това не е просто инструмент за репутация, който показва зелена икона на катинар в браузъра, която казва „Защитено“; по-скоро инсталирането на SSL сертификат и принуждаването на всички URL адреси да работят на „https“ е достатъчно, за да превърне уебсайта ви от отворена книга в загадъчен свитък.
Ако не разбирате как се случва това, моля, прочетете за нещо известно като a атака „човек по средата“..
Друг начин за прихващане на трафика, протичащ от вашия компютър към сървъра, е пакетно подслушване, което е пасивна форма на събиране на данни и дори не е необходимо да полага усилия, за да се позиционира по средата.
За сайтове, които изпълняват обикновен „HTTP“, лицето, което прихваща мрежовия трафик, вашите пароли и номера на кредитни карти изглеждат ясен, обикновен текст.
Източник: comparitech.com
Страшен? Много!
Но след като инсталирате SSL сертификат и всички URL адреси се преобразуват в „https“, тази чувствителна информация се показва като безсмислици, които само сървърът може да дешифрира. С други думи, не изпотявайте тези няколко долара на година. 🙂
Заключение
Ще поставите ли тези пет неща под контрол, за да защитите добре уебсайта си?
Нищо подобно. Както се казва в безброй статии за сигурност, никога не сте 100% защитени, но е възможно да елиминирате голям клас от тези проблеми с разумни усилия. Може да обмислите използването на облачен WAF на SUCURI, за да защитите сайтовете си холистично.