Защитете WordPress-а си от Хакери в 6 Лесни стъпки

107 Flares 107 Flares ×

Как да защитим WordPress от хакерски атаки? Защитете WordPress-а си от Хакери в 6 Лесни стъпки

Как да защитим WordPress от хакерски атаки?

Досега лично съм пробвал буквално казано всичките wordpress плъгини за защита, но резултата е никакъв и сайта беше долу. Накрая реших сам да направя цялата тази работа. Защитата е кратка и се състои от две основни неща: .htaccess и chmod

Накратко – трябва да защитиме папките от обикновените потребители, да свалим някои приоритети и да си поиграем малко с .htaccess.

Стъпка 1

Като за начало е добре да защитите папката /wp-admin/, която ще може да се вижда от вас самия. След като поставите .htaccess файла в папката /wp-admin/, остава само да напишете IP адресите които могат да посещават администраторския панел. Код за поставяне в .htaccess файла:

order deny, allow
deny from all
# IP адрес (на компютъра ви вкъщи)
allow from xxx.xxx.xxx.xxx
# IP адрес (на компютъра ви на работа)
allow from xxx.xxx.xxx.xxx

Стъпка 2

След това почваме работа по папката /wp-content/, която също е важна. Проверете дали папката има празен index.php и ако има такъв, нулирайте

изцяло неговия chmod (т.е. chmod = 000).

Стъпка 3

След това сложете chmod (750) на всички папки в /wp-content/ oсвен на /themes/ и /plugins/. След като вече сте във /themes/ или /plugins/ проверете пак дали има празен index.php файл и нулирайте неговия chmod (т.е. chmod = 000).

Влезте в папката на вашата тема (тази, която използвате в момента) и добавете .htaccess файл съдържащ :

<Files ~ “\.php$”>

Order Allow, Deny

allow from localhost

Deny from All

</Files>

Стъпка 4

Следва /wp-includes/. При него просто трябва във всяка папка да има index.php с chmod (т.е. chmod = 000)

 

Стъпка 5

В основната директория, отворете .htaccess и добавете следния код (предполага се, че вече wordpress е променял вашия .htaccess) :

<files wp-config.php>
order allow,deny
deny from all
</files>

Стъпка 6

След това променете chmod на файла wp-config.php на 600.

 

Това е цялата работа.

Източник на Оригинала: Кацаров

Забележка: Имайте предвид, че ако имате други сайтове на хостинга си, особено ако са нови cms (незащитени) този урок не може да гарантира сигурността на вашия сайт.

Можете да коментирате чрез:

Loading Facebook Comments ...

28 SEO коментара на “Защитете WordPress-а си от Хакери в 6 Лесни стъпки”

  1. Христо Стоянов каза:

    Авг. 08, 11 в 11:20

    адски полезна статия. търсил съм нещо подобно на български, но не открих така описано. сега остана като се опитам да го направя както си го описал и да ми се получи, в което малко се съмнявам :))))))

  2. Кристиян Кацаров каза:

    Авг. 08, 11 в 11:42

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

  3. Томислав Петков каза:

    Авг. 08, 11 в 13:43

    Браво Евгени! Супер статия. Много ми харесва и непременно ще го изпробвам. От два дена ровя за информация как да си защитя базата данни и това най-много ми харесва :)

  4. Ивайло Спасов каза:

    Авг. 08, 11 в 14:36

    Чудесна статия.

    Ако можеш да извадиш подобна информация за Drupal, ще е направо чудесно! :)

  5. seo Георги Стефанов каза:

    Авг. 08, 11 в 15:05

    Ако след изпълнението на 1-ва стъпка получите “Internal Server Error”, това е защото ви е домързяло и сте copy-paste-нали кода за .htaccess. В този случай махнете интервала след запетайката в първия ред “order deny, allow”. Всички файлове .htaccess е добре да имат chmod=644.
    Тези стъпки няма да ви защитят напълно, но ще спрат голямо количество от атаките.

  6. инж. Евгени Йорданов каза:

    Авг. 08, 11 в 22:26

    Томи, аз тук не предлагам защита на базата данни, а по-скоро на файловата система на CMS-а WordPress. За самата база данни, единствената защита, която ти можеш да направиш е да не е стандартната база данни, със стандартното разширение на таблиците. Всичко останало по защитата на базата си зависи от защитите, които са вдигнали от хостинг провайдера ти.

  7. Александър Атанасов каза:

    Авг. 08, 11 в 23:08

    Съжалявам, че ще го нарека така, но този морално остарял начин на защита е единствено фиктивен, ако атаката бъде remote. Колко чисти wordpress-a сте виждали хакнати отвън?

    Писал съм по-въпроса и преди – всичко е въпрос на хостинг секюрити, ако е домашната Ви машинка – да правете това и бъдете спокойни, но ако сте на споделен хостинг, това не ви върши абсолютно никаква работа. Там принципа е вътрешен, никой не атакува отвън, защото няма смисъл. (Говоря за WordPress в който добре знаете, какви плъгини слагате, а не nulled.)

  8. Димитър Георгиев каза:

    Авг. 09, 11 в 12:46

    Има и още неща като смяна на името на админ акаунта и т.н. Иначе полезно, но за някои може да е твърде сложно. Полезно като цяло, както обикновено Евгени ;)

  9. seo blog каза:

    Авг. 09, 11 в 14:55

    Ще го пробвам и аз пък може и да проработи ;-) Мерси за инфото Гена

  10. THE_OAK каза:

    Авг. 10, 11 в 11:00

    Много полезна статия!

  11. Orlio каза:

    Авг. 11, 11 в 12:11

    @Александър Атанасов
    Мога да те уверя, че 99% от атаките са RFI LFI и FTP. Почти не съм виждал атака, която да проблем на самият хостинг провайдер.
    Това, което ми се е случило да видя, е да бъде хакнат един акаунт от друг хакнат акаунт, но атаката пак беше RFI.
    Така, че статията си е много добра. Освен, да мърмориш, че това е морално остарял начин. Не виждам да си предложил по-модерен.

  12. Александър Атанасов каза:

    Авг. 11, 11 в 20:12

    Въобще не е мърморене. В това, което съм писал има това, което търсиш. Хостинг провайдъра трябва да предлага сигурна среда за клиентските си сайтове.

    Ето това, просто не трябва да се случва:

    //Това, което ми се е случило да видя, е да бъде хакнат един акаунт от друг хакнат акаунт, но атаката пак беше RFI.//

    Разбира се хостинг-а няма как да гарантира и сигурността на плъгините, но това вече е отговорност на самия потребител, който в случая с един htpasswd/hstacc или allow from няма да спре атакуващия.

    Oбобщение: Сигурna хостинг среда + wordpress в който знаете какви плъгини (платени или пренаписани, ако са имали дупки)сте слагали и проблем нямате.

  13. seo blog каза:

    Авг. 12, 11 в 10:11

    Решат ли хакери които знаят какво правят да проникнат в сайта, ще го направят. Въпроса е в желанието и уменията на проникващия, а не в сигурността на сайта или надеждността на хостинга. Ако хостинга ти е добър максимум за един ден ще ти възстановят проблема, ако не ще се сбогуваш със сайта.Сърбал съм им попарата но определено Гената помага да ги затрудниш.

  14. Orlio каза:

    Авг. 13, 11 в 16:09

    @Александър Атанасов

    Вариант 1. По който може да се случи това, което не трябва да се случи. Давам само за пример системата, но това се отнася за всяка CMS.
    Качваш някаква Joomla и я зарязваш необновявана с години, ползваш много cool плъгини, които са пълни с дупки.
    Какво следва, чупят ти Joomla та, катерат ти шеловете, и оттам не им пречи нищо следващия хубавец да изяде дървото от твоя акаунт с RFI.
    Да не говорим, колко още варианра има, но не желая да се впускам в излишни флеймове.
    За мен статията е полезна, и не ми изглежда даже въобще остаряла :)
    Най-често системи се трошат през допълнително инсталирани модули и компоненти. Много рядко се трошат нови системи. Не, че не е невъзможно, но е в редки случаи. Специално за Joomla 1.5.х не желая да уточнявам номера на версията, но толкова лесно се експлойтва, и се взима достъп до администрацията и, че просто на човек може да му настръхне косата. Мога само да уточня, че във версия > 1.5.22 този проблем го няма.

  15. инж. Евгени Йорданов каза:

    Авг. 13, 11 в 19:15

    Блаходаря ти за изчерпателния и обоснован коментар!

  16. Интериорни врати каза:

    Авг. 20, 11 в 13:52

    Преди време попаднах на една тема, в която се обсъждаше как определена група хора, вкарва в голям брой сайтове свои линкове и печели от продажба на афилейт продукти, само че бяха попаднали на сайта на човек, който разбира и той от своя страна влезе в техните сървъри и беше публикувал как точно правят номера. Интересното е, че самите хакери не защитават своя двор. Иначе имам няколко WP, в които съм направил описаните стъпки за защита, но за цитираната Джумла 1.5, абсолютно нищо не съм направил и точно както казва Orlio сайта е зарязан необновяван и е с няколко cool плъгини. Време е нещо да направя по въпроса, да не изпищя по някое време..

  17. Дилян каза:

    Авг. 22, 11 в 04:08

    Също така може да добавиш и

    order allow,deny
    deny from all

    ServerSignature Off

    /Вместо празните index.php
    Options All -Indexes

    към .htaccess

  18. Дилян каза:

    Авг. 22, 11 в 04:11

    Опс, така не ставало, тук може да видите какво имам в предвид http://pastebin.com/2XjhYT0D

  19. Андрей Димитров каза:

    Сеп. 12, 11 в 09:36

    Евгени, когато сложа .htaccess файла в папката /wp-admin получавам грешка 404.

    Копирам точно този кой, който си дал, като заменям цифрите xxx.xxx.xxx.xxx с моето IP.

    Къде бъркам?

  20. инж. Евгени Йорданов каза:

    Сеп. 12, 11 в 10:18

    Пращам ти файла, готов за замяна на IP адреса в съответния файл. Предполагам, че най-вероятно, въпреки че очаквам, че го знаеш, най-вероятно не си слагаш реалното IP, а някакво вътрешно. Не зная как са доставчиците в Пловдив, та затова и предполагам най-лошото. За да видиш реалното си IP, можеш да ползваш онлайн услуга, като например тази: http://whatismyipaddress.com/
    С нейна помощ ще видиш реалното си IP, което да заложиш и в .htaccess файла.

  21. Андрей Димитров каза:

    Сеп. 12, 11 в 10:20

    Точно с такъв туул проверих IP-то си, Гена :-)

  22. Любен каза:

    Ное. 08, 11 в 12:31

    Здравейте,

    Благодаря много за статията, приложих я на практика и имам един въпрос:

    Отнася се за стъпка 3 – Понякога използвам линкове към снимки, качени в wp-content/uploads, и в случай, че задам chmod=750 те вече не са достъпни от линковете. Също така се появи и проблем с функцията slideshow на плъгина NextGen, който ползва директория gallery.

    Та въпросът е: Мога ли и в тези директории да сложа заключен index.php (не знам точно какъв е смисълът, просто повтарям стъпките от статията), или да оставя нещата както са си били?

    Благодаря предварително за отговора:)

  23. инж. Евгени Йорданов каза:

    Ное. 08, 11 в 14:26

    Радвам се, че са ви помогнали тези стъпки. Колкото това, какво да направите с казуса с WP-Upload и с Gallery. Направете CHMOD на съответните директории 644 и разположете в тях по един празен index.php, чиито CHMOD само да е 000, както е споменато по-горе. Това би трябвало да оправи проблемите ви.

  24. Любен каза:

    Ное. 08, 11 в 16:14

    Благодаря, за съжаление с 644 пак не се отварят снимките, когато са дадени като линк в някой форум, например…оставям ги 755 с 000 index.php. Мерси още веднъж.

  25. Мая каза:

    Мар. 04, 12 в 11:19

    Искам да попитам относно префикса на базата. Може ли да се сменя впоследствие? Това става от конфигурационния файл, нали?

  26. инж. Евгени Йорданов каза:

    Мар. 05, 12 в 09:37

    Да, смяната от конфигурационна гледна точка се извършва от конфигурационния файл wp-config.php. Но всъщност преди това, трябва да ссе промени името на всяка една от таблиците в базата, чрез database manager-а ви (в общия случай phpMyAdmin) така, че всяка една от таблиците в базата да съдържа префикса. Реално смяната в конфигурационния файл единствено указва на WordPress къде да си търси таблиците в базата, а не как да ги структурира.

  27. Мая каза:

    Мар. 06, 12 в 12:14

    Благодаря за отговора. Ако не е много нахално от моя страна, бих искала да кажете две-три думи за .htaccess. Поизчетох доста статии в нета, свързани с този файл, и си оформих един сборен, така да се каже:

    RewriteEngine On
    RewriteBase /
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    order allow,deny
    deny from all

    ServerSignature Off

    order allow,deny
    deny from all

    Options All -Indexes

    RewriteEngine on
    RewriteCond %{HTTP_REFERER} !^$
    RewriteCond %{HTTP_REFERER} !^http://(www\.)?yourdomain.com/.*$ [NC]
    #RewriteRule \.(gif|jpg)$ – [F]
    #RewriteRule \.(gif|jpg)$ http://www.yourdomain.com/stealingisbad.gif [R,L]

    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} POST
    RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
    RewriteCond %{HTTP_REFERER} !.*yourdomain.com.* [OR]
    RewriteCond %{HTTP_USER_AGENT} ^$
    RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]

    AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/x-javascript text/plain text/xml application/xml application/xhtml+xml application/rss+xml

    Header append Vary User-Agent

    Мога ли да го кача в този му вид? Има ли реална полза от цялата работа или защитата на WordPress си е достатъчна? Благодаря предварително!

  28. Мая каза:

    Мар. 06, 12 в 12:16

    Офф, при публикуването на коментара се изгуби част от редовете, но се надявам, че ще разберете каква ми е била идеята.


107 Flares Facebook 77 Google+ 13 Twitter 10 LinkedIn 7 107 Flares ×
Предишна публикация:
rel nofollow
Сигурност: Опити за измама при подновяване на домейн

Напоследък зачестиха опитите за измами при подновяване на регистрацията на домейни. В случай, че получите e-mail съобщения от съмнителни компании,...

Затвори