Неведнъж съм споменавал за силата на WordPress и за това колко стабилна, гъвкава и надеждна система е за малки, че дори и средни уеб сайтове. Въпреки че разработчиците са се погрижили системата да е достатъчно добре подсигурена и трудна откъм нежелани пробиви и атаки, все още има какво да се направи, за да се увеличи сигурността. Съществуват няколко простички правила, които, ако ги спазваме, ще направим задачата на лошите хакери много, много трудна, чак невъзможна 
Защита на конфигурационния файл (wp-config.php)
Най-важният файл от системата. В него се съдържа информацията, необходима за връзка към базата данни. Сами разбирате колко е важно да не бъде разбит от външно лице.
Ако инсталацията на WordPress е директно във вашата /public_html директория, преместете wp-config.php във root директорията на сървъра. Т.е. изнесете го извън /public_html папката (тази, в която качвате файловете за вашия уебсайт (може да се казва /www)). Главната (root) директория на сървъра никога не е достъпна директно през HTTP от браузера и това допълнително ограничава достъпът до всеки файл, записан там. Няма нужда да се притеснявате, че файлът wp-config.php е преместен – WordPress ще си го намери 
Ако поддържате няколко инсталации на WordPress, няма как да преместите всичките конфигурационни файлове на root директорията, тъй като те са с едно и също име. В този случай просто ги защитете с един .htaccess файл:
<files wp-config.php>
Order allow,deny
deny from all
</files>
Така сървърът ще реже всякакъв достъп до файла през HTTP.
Измислете достатъчно сложни и дълги Security Keys
Тези Security Keys представляват константи, които се задават във файла wp-config.php и хич не са за пренебрегване, тъй като те генерират различни и уникални хешове, които се добавят към паролите, куукитата, сесиите, и правят системата доста по-трудна за хакване. Въпросните ключове са AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY и NONCE_KEY. Общо взето стойностите им трябва да изглеждат горе-долу така:
define('AUTH_KEY', ':dr+%/5V4sAUG-gg%aS*v;&xGhd%{YKC^Z7KKGh');
define('SECURE_AUTH_KEY', 'TufWOuA _.t>#+hA?^|3RfGTm>@*+S=8');
define('LOGGED_IN_KEY', 'S~AACm4h1;T^\"qW3_8Zv!Ji=y|)~5i63JI');
define('NONCE_KEY', 'k1+EOc-&w?hG8j84>6L9v\"6C89NH?ui{*3\\(t');
Не се стряскайте от стойностите, НЕ ТРЯБВА ДА ГИ ПОМНИТЕ! Пак казвам, това са стрингове, които се използват при хешването на пароли и бисквитки, следователно колкото по-дълги и сложни са, толкова по-добре за вас . Ако не можете да си измислите ваши, WordPress ви предлага API, което ще ви помогне, но лично аз ви съветвам да си напънете малко мозъците и да си ги измислите сами. Ъ, кви мозъци бре, просто поскачайте безразборно няколко секудни по клавиатурата и сте готови 
Защита на базата данни
Представката за таблиците на WordPress е дефинирана в конфигурационния файл (wp-config.php) и по подразбиране е "wp_". Просто си измислете друга, по дяволите
Защита на администраторския акаунт
При инсталацията на WordPress автоматично се създава администраторски акаунт с име admin и случайно генерирана парола. За съжаление, системата не позволява преименуване на акаунтите, а не е добре да се оставя това име, тъй като масово опитите за brute force break на администраторски акаунт са с username: admin и просто опитват различни пароли.
Създайде нов акаунт от Потребители, и му дайте администраторски права. Измислите си дълга и сложна парола. Нека символите са повече; нека има главни и малки букви, цифри и знаци от сорта на !, $ и пр. Логнете се с новия акаунт и отново от Потребители изтриите admin акаунта. Ако имате създадени публикации/страници с потребителя admin, то не забравяйте при изтриването му те да се прехвърлят на новия ви акаунт!
А можете и просто директно през базата данни в таблицата users да смените името admin на друго, по ваше желание. Но препоръчвам първия метод, тъй като новият административен акаунт ще дойде с ново ID, т.е. няма да е 1. По-добре така, за всеки случай
Защита на административната директория (/wp-admin/)
Ако се питате има ли начин да се преименува админ папката wp-admin на нещо друго, веднага ви отговарям – няма начин . Името "wp-admin" е хардкорнато, среща се над 100 пъти из файловете. Можете да го смените с един мощен find/replace с любимия ви редактор, но по този начин ще загубите възможността за update на системата. Или при всеки ъпдейт ще трябва отново да сменятте името. Въпрос на преценка, дали ви удовлетворява тоя вариант, или не.
Все пак потърсих информация по въпроса с преименуването. Намерих едно добро "решение" на Michi Kono. Решение в кавички, защото изглежда е работело при версия на WordPress 2.3.* и надолу, но след версия 2.5 не работи. Въпреки това, нека все пак да обясня. Идеята е много добра. Да речем, че вместо "wp-admin", искаме да кръстим администрационната папка "customadmin". Добавят се няколко редирект условия и команди в главния .htaccess файл. Всеки един request, в който се съдържа името wp-admin и НЕ се съдържа GET променливата "YOURSECUREPHRASE" връща грешка, че страницата не може да бъде намерена. Следващото условие е, request в който се съдържа името customadmin да препраща към wp-admin?YOURSECUREPHRASE . По този начин успешно избягваме от условието да бъдем препратени към страница за грешка или несъществуващ файл при всеки request, в който викаме "wp-admin".
Защо не работи в новите версии на WP? Въведен е метод, който проверява REQUEST_URI-то на всеки един php файл от wp-admin папката. Ако файлът не се извиква от /wp-admin/ , т.е. този стринг го няма във REQUEST_URI-то, файлът препраща към страницата за логин. И така се получава един безкраен цикъл.
Ясно, няма как да сменим името на wp-admin към този момент. Как да я подсигурим обаче? Има две неща, които можем да направим.
Защитете директорията на ниво сървър – с .htaccess и mod_access. Създайте един потребител, с достатъчно сложна парола; създайте един .htaccess файл във wp-admin директорията, и един .htpasswd. Във .htaccess пишем:
# път до .htpasswd файла
AuthUserFile /path/to/yoursite/wp-admin/.htpasswd
AuthName EnterPassword
AuthType Basic
require valid-user
Във .htpasswd пишете всички потребители:пароли, които искате да имат достъп до директорията. Всяко потрбителско име се пише на нов ред, следвано от двуеточие (:), и веднага след него криптираната парола.
myuser:$apr1$f3TOu...$MSAsViNERcB.6i3rdPO7/1
Относно криптирането на паролата, ползвайте този онлайн криптиращ инструмент.
Ако сървърът ви поддържа SSL, ползвайте HTTPS за wp-admin директорията. Прави се много лесно, просто добавете define(’FORCE_SSL_ADMIN’, true); някъде във конфигурационния файл (wp-config.php).
Ограничете грешните опити за вход до минимум
По подразбиране, WordPress няма ограничение върху грешните опити за login (вход). По този начин съществува опасност от "счупване" на паролата с brute force. Пускат ви няколко стотин ботове, които непрекъснато опитват различни комбинации от потребителски имена и пароли, идеята е да уцелят правилните и да ви влязат в администрацията. Теоретично, ако username-a и паролата ви са достатъчно сложни, ще им е необходимо доста време да ги уцелят. Нека все пак обаче да ги ограничим
Limit Login Attempts е плъгин, който ще свърши тази работа. Единственото, което трябва да направите, е да го изтеглите и инсталирате. Дори не е необходимо да му пипате и настройките по подразбиране. А те са следните: всяко IP има право на 4 грешни опита, след което IP-то се заключва за 20 минути – време, в което дори да се въведат правилни име и парола, системата няма да даде достъп на това IP. 4 такива заключвания водят до заключване за 24 часа Тези настройки можете да си ги променяте по ваша преценка, разбира се – в администрацията, Options -> Limit Login Attempts.
Плъгинът остранява и друг недостатък на WordPress. По подразбиране, системата дава информация дали само username-a е грешен; ако съществува такова потребителско име изписва, че е грешна паролата. А това е доста ценна информация за недоброжелателите, тъй като те ще знаят кога са уцелили съществуващо потребителско име, и вече следват опити само с пароли. Limit Login Attempts винаги ще връща грешка "Невалидно потребителско име ИЛИ парола"
Направих български превод за този plug-in, можете да го изтеглите: limit-login-attempts-bg_BG
Защита на папките и файловете. Права
Последно по ред, но не и по важност. Даже трябваше с това да започна. Изобщо не подценявайте правата, защото може да имате сериозни главоболия, и всички неща, изписани по-горе да се окажат безполезни!
Във файловите системи файловете и директориите имат различни права в зависимост от това кой потребител може да ги чете, да ги модифицира/трие/пише в тях, и да ги execute-ва. Пример за потребител – FTP user-a, с който се логвате, е един потребител; Apache сървърът е друг и т.н. Уверете се, че всички WordPress директории имат пълни права само за техния създател -rwxr-xr-x (CHMOD 755). Това означава, че само потребителят, създал папката, има пълни права да пише и execute-ва. Групите и публичните потребители нямат права за писане. Нека всички файлове имат права -rw-r--r-- (CHMOD 644). Тези права се задават посредством FTP клиент, с командата CHMOD. Повече информация относно правата.
Добре, ами какво става с wp-content/uploads директорията? Не мога да качвам файлове!
Масова практика е да се задават пълни права на wp-content/uploads директорията (CHMOD 777) – ГРЕШКА! 777 означава, че всеки, АМА АБСОЛЮТНО ВСЕКИ може да записва в тази директория, и бедна ви е фантазията какви гадории могат да ви хвърлят там! Ако ъплоуд директорията ви има права 755 и не можете да качвате/изтривате файлове през админ панела на WordPress, то значи най-вероятно сте я създали с вашия FTP потребител.
Как да поправим нещата:
- изтривате папката uploads
- давате пълни права на wp-content папката (CHMOD 777)
- отивате в админ панела на WordPress и upload-вате някакъв файл, няма значение какъв, към публикация или страница, без значение
- връщате старите права на wp-content директорията (CHMOD 755)
Това е всичко. При качването на файл WordPress ще потърси wp-content/uploads директорията. Тя не съществува, следователно системата ще се опита да я създаде. Родителската директория wp-content има пълни права за писане и това не е проблем. След това връщаме старите права, но автор на uploads директорията вече е сървърът (apache), и само той има пълни права над нея и всички файлове/директории вътре. По този начин получавате пълна фунцкионалност на системата, включително да качвате и триете файлове през контролния панел, и в същото време директорията е защитена от качването на файлове-вредители отвън.
Ако с FTP клиента сте качили някакви файлове преди това – сори, но ще трябва да ги качите пак. Това е положението. Вариант е да си напишете малък php скрипт, който да обходи uploads директорията и да направи пълно копие на всички папки и директории вътре в нова директория, uploads2 да речем. След копирането изтривате uploads папката, и новата uploads2 я преименувате на uploads.
Заключение
Спазвайте всички изброени дотук неща и спете спокойно А, да, и не забравяйте редовно да си обновявате WordPress до последна версия
По темата (на английски): Hardering WordPress, Changing File Permissions
