Пашыраныя налады бяспекі WordPress праз файл wp-config.php

Пашыраныя налады бяспекі праз файл wp-config.php — гэта канфігурацыі для абароны доступу да базы дадзеных, узмацнення сесійных ключоў, адключэння рэдагавання файлаў, бяспечнага кіравання адладкавай інфармацыяй, прымусовага выкарыстання SSL і абмежавання шляхоў да крытычных дырэкторый. Карацей кажучы, wp-config.php — гэта адзін з цэнтраў бяспекі вашага сайта на WordPress; правільныя налады памяншаюць паверхню нападу, зніжаюць рызыку несанкцыянаванага доступу і абмяжоўваюць шкоду ў выпадку інцыдэнту бяспекі.

Большасць уладальнікаў сайтаў, якія ўсталёўваюць WordPress, успрымаюць файл wp-config.php толькі як тэхнічны файл для ўводу назвы базы дадзеных, імя карыстальніка і пароля. Аднак насамрэч гэты файл з'яўляецца крытычна важнай часткай архітэктуры бяспекі жывога сайта. Асабліва для інтэрнэт-крамаў, сістэм з рэгістрацыяй, карпаратыўных сайтаў і блогаў з высокім трафікам правільна наладжаны файл wp-config.php забяспечвае магутны ахоўны пласт ад простых бот-атак, маніпуляцый з файламі праз панэль, уцечкі паведамленняў пра памылкі і спробаў крадзяжу сесій.

У гэтым кіраўніцтве для блога Hostragons мы пакрокава разгледзім пашыраныя налады бяспекі, якія можна прымяніць да файла wp-config.php. Мы растлумачым прызначэнне кожнай налады, сітуацыі, у якіх мы рэкамендуем яе выкарыстоўваць, і на што варта звярнуць увагу перад ужываннем — проста, але з тэхнічнай дакладнасцю. Калі ў вас яшчэ няма бяспечнай і сучаснай інфраструктуры хостынгу, разам з умацаваннем wp-config.php важны і выбар надзейнага WordPress-хостынгу. У гэтым кантэксце могуць быць карыснымі старонкі Пакеты WordPress хостынга і Рашэнні для бяспечнага вэб-хостынгу.

Што такое файл wp-config.php і чаму ён крытычны для бяспекі?

wp-config.php — гэта канфігурацыйны файл, размешчаны ў каранёвым каталогу WordPress, які захоўвае асноўныя працоўныя параметры сайта. WordPress праз гэты файл падключаецца да базы дадзеных, счытвае ключы бяспекі, вызначае паводзіны адладкі, кіруе аперацыямі файлавай сістэмы і запускае некаторыя пашыраныя канстанты. Таму змесціва гэтага файла значна больш адчувальнае, чым звычайны файл тэмы.

Звычайна гэты файл змяшчае наступную крытычную інфармацыю:

• Назва базы дадзеных, імя карыстальніка, пароль і звесткі пра сервер
• Унікальныя ключы аўтэнтыфікацыі і "солі" (Salts), вядомыя як Authentication Unique Keys
• Прэфікс табліц базы дадзеных
• Налады адладкі і вядзення логаў
• Канстанты, якія кантралююць рэдагаванне файлаў, абнаўленні і паводзіны SSL
• Працоўныя налады, такія як ліміт памяці WordPress і дырэкторыя часовых файлаў

Калі зламыснік атрымае доступ да змесціва wp-config.php, ён можа завалодаць дадзенымі для падключэння да базы дадзеных. У такім выпадку пад пагрозай апынуцца не толькі панэль WordPress, але і ўліковыя запісы карыстальнікаў, запісы заказаў, формы, кантэнт і прыватныя дадзеныя кліентаў у базе дадзеных. Таму абарона файла wp-config.php з'яўляецца адным з асноўных крокаў у забеспячэнні бяспекі WordPress.

Перад пачаткам: План рэзервовага капіявання, тэсціравання і доступу

Нават невялікая сінтаксічная памылка ў файле wp-config.php можа прывесці да "белага экрана смерці", разрыву злучэння з базай дадзеных або страты доступу да панэлі кіравання. Таму перад унясеннем змен рэалізуйце трохэтапны план бяспекі.

1. Зрабіце поўную рэзервовую копію

Спачатку зрабіце рэзервовую копію файлаў і базы дадзеных. Недастаткова проста спампаваць файл wp-config.php на кампутар; паколькі змены могуць паўплываць на злучэнне з базай дадзеных, яе копія таксама важная. Калі на вашай панэлі кіравання ёсць функцыя аўтаматычнага рэзервовага капіявання, праверце дату апошняй копіі. Пры неабходнасці стварыце копію ўручную. З гэтым дапаможа змест Кіраўніцтва па рэзервовым капіраванні сайта.

2. Уносьце змены па адной

Замест таго каб дадаваць 8 ці 10 налад бяспекі адначасова, пасля кожнай змены тэсціруйце сайт, панэль кіравання і крытычныя формы. Напрыклад, спачатку адключыце рэдагаванне файлаў, затым праверце сайт. Потым наладзьце адладку. Гэты метад дазваляе хутка вызначыць, які радок выклікаў праблему, калі ўзнікне памылка.

3. Падрыхтуйце доступ праз FTP або файлавы менеджэр

Калі wp-config.php будзе захаваны з памылкай, вы можаце страціць магчымасць увайсці ў панэль WordPress. Таму пераканайцеся, што ваш доступ праз файлавы менеджэр cPanel, SFTP або бяспечную перадачу файлаў працуе. Выкарыстанне SFTP больш бяспечнае, чым FTP, паколькі злучэнне адбываецца ў зашыфраваным выглядзе. Для бяспечнага доступу можа спатрэбіцца кіраўніцтва што такое SFTP і як яго выкарыстоўваць.

Кароткі агляд налад бяспекі wp-config.php

Табліца ніжэй змяшчае практычны агляд асноўных і пашыраных налад бяспекі, апісаных у гэтым кіраўніцтве. Перш чым прымяняць іх на жывым сайце, ацаніце кожны радок у адпаведнасці з патрэбамі вашага сайта.

Узмацніце ключы бяспекі і значэнні "соляў"

Бяспека сесій WordPress забяспечваецца ключамі AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY і іх адпаведнымі "солямі" (salt) у wp-config.php. Гэтыя ключы робяць карыстальніцкія cookies і працэсы праверкі сесій больш бяспечнымі. Калі ключы слабыя, стандартныя або даўно не змяняліся, бяспека сесій можа быць аслаблена.

Рэкамендуецца генераваць новыя выпадковыя ключы праз афіцыйны генератар сакрэтных ключоў WordPress. Звычайна гэта значэнні даўжынёй больш за 64 сімвалы, якія змяшчаюць выпадковыя сімвалы і якія практычна немагчыма адгадаць. Вам дастаткова замяніць існуючыя радкі ў wp-config.php на новыя ключы.

Эфект ад гэтага дзеяння адназначны: усе актыўныя сесіі карыстальнікаў будуць завершаны, і ім спатрэбіцца ўвайсці зноў. Калі вы падазраяце, што ўліковы запіс адміністратара быў скампраметаваны, абнаўленне значэнняў "соляў" — гэта хуткі экстраны крок. Абнаўляць гэтыя ключы кожныя 6 месяцаў або пры падазрэнні на парушэнне бяспекі — добрая практыка.

Адключыце рэдагаванне файлаў праз панэль

У панэлі кіравання WordPress ёсць рэдактар, які дазваляе змяняць файлы тэм і плагінаў. Хоць падчас распрацоўкі гэта зручна, на жывых сайтах гэта стварае сур'ёзную рызыку. Калі зламыснік атрымае доступ да ўліковага запісу адміністратара, ён зможа дадаць шкоднасны PHP-код праз файлавы рэдактар у панэлі.

Вы можаце адключыць рэдагаванне файлаў з панэлі, дадаўшы наступную канстанту ў файл wp-config.php: define('DISALLOW_FILE_EDIT', true);

Гэтая налада дэактывуе рэдактар файлаў тэм і плагінаў у панэлі WordPress. Мы рэкамендуем актываваць яе па змаўчанні для блогаў з штодзённымі публікацыямі, карпаратыўных сайтаў і крамаў на WooCommerce. Калі патрабуюцца змены файлаў, іх варта рабіць праз SFTP, Git або бяспечныя працэсы разгортвання.

У якасці больш прасунутай опцыі можна выкарыстоўваць канстанту DISALLOW_FILE_MODS, якая таксама абмяжоўвае загрузку і абнаўленне файлаў. Аднак, паколькі гэтая налада можа таксама блакаваць абнаўленні плагінаў і тэм, яе варта выкарыстоўваць толькі на вельмі адчувальных сістэмах, дзе змены не павінны адбывацца па-за акном абслугоўвання.

Прывядзіце налады адладкі ў адпаведнасць з жывым сайтам

У асяроддзі распрацоўкі WordPress карысна ўключаць WP_DEBUG: вы бачыце памылкі, знаходзіце несумяшчальныя плагіны і дыягнастуеце праблемы тэм. Аднак на жывым сайце паведамленні пра памылкі, якія выводзяцца на экран, могуць утрымліваць карысную для зламысніка інфармацыю: шлях да сервера, назву плагіна, месцазнаходжанне файла, падказкі да запытаў базы дадзеных і версію PHP.

Бяспечны падыход у жывым асяроддзі наступны: не паказваць памылкі наведвальнікам, а пры неабходнасці запісваць іх у спецыяльны лог-файл. Для гэтага WP_DEBUG павінен быць false; калі на этапе распрацоўкі патрабуецца лагаванне, WP_DEBUG_LOG павінна быць true, а WP_DEBUG_DISPLAY — false. Прыклад логікі наступны: define('WP_DEBUG', false); define('WP_DEBUG_DISPLAY', false);

Калі вам трэба даследаваць памылку, уключыце лагаванне на кароткі час, вырашыце праблему і зноў адключыце. Таксама пераканайцеся, што лог-файл недаступны з агульнадаступнай дырэкторыі. Бо файл debug.log часам можа стварацца побач з коранем сайта і быць чытэльным звонку на няправільна наладжаных серверах. Каб паменшыць такія рызыкі, крытычна важная правільная канфігурацыя хостынгу. Як кіраваць журналамі памылак WordPress і Бяспечны WordPress хостынг з'яўляюцца натуральным працягам гэтай тэмы.

Зрабіце SSL і бяспеку панэлі кіравання абавязковымі

SSL-сертыфікат шыфруе трафік паміж карыстальнікам і серверам. Паколькі ўваход у панэль WordPress ажыццяўляецца з выкарыстаннем імя карыстальніка і пароля, адміністрацыйны трафік абавязкова павінен ісці праз HTTPS. Гэтая налада асабліва важная для каманд, якія атрымліваюць доступ да панэлі кіравання з агульных сетак, па-за офісам або праз мабільныя злучэнні.

У wp-config.php можна зрабіць SSL абавязковым для панэлі кіравання з дапамогай канстанты FORCE_SSL_ADMIN: define('FORCE_SSL_ADMIN', true);

Для карэктнай працы гэтай налады на вашым дамене павінен быць усталяваны сапраўдны SSL-сертыфікат. Калі вы яшчэ не выкарыстоўваеце SSL, спачатку завяршыце ўстаноўку сертыфіката. SSL — гэта базавае патрабаванне не толькі для бяспекі, але і для даверу карыстальнікаў і SEO. Каб азнаёміцца з варыянтамі SSL на Hostragons, наведайце старонку Прадукты сертыфікатаў SSL, а для кіравання даменам — Праверка дамена і рэгістрацыя дамена.

Калі пасля прымусовага ўключэння SSL узнікла памылка бясконцай пераадрасацыі, звычайна гэта азначае, што канфігурацыя проксі, CDN або балансіроўшчыка нагрузкі вызначаецца няправільна. У такім выпадку варта праверыць загалоўкі HTTPS на баку сервера і налады адраса сайта WordPress.

Больш бяспечнае кіраванне дадзенымі базы дадзеных і прэфіксам табліц

Значэнні DB_NAME, DB_USER, DB_PASSWORD і DB_HOST у файле wp-config.php дазваляюць WordPress падключацца да базы дадзеных. Гэтыя дадзеныя павінны быць надзейнымі, а прывілеі — абмежаванымі. Адна з самых частых памылак — наданне карыстальніку базы дадзеных больш правоў, чым неабходна.

Для жывога сайта на WordPress рэкамендуецца, каб карыстальнік базы дадзеных меў толькі тыя прывілеі, якія яму сапраўды патрэбныя. Звычайна дастаткова правоў SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER і INDEX. Выкарыстанне ва ўсталёўцы WordPress карыстальнікаў з шырокімі правамі, якія маюць доступ да ўсіх баз дадзеных на ўзроўні кіравання серверам, з'яўляецца рызыкоўным.

Правільны падыход да прэфікса табліц

Стандартны прэфікс табліц WordPress — wp_. Пры новых усталёўках змяненне яго на іншае, больш выпадковае значэнне ўскладняе працу аўтаматычных інструментаў для атак. Напрыклад, замест wp_ можна выбраць кароткі, але цяжкі для адгадвання прэфікс накшталт hr7x_. Аднак змяненне прэфікса табліц на існуючым сайце не абмяжоўваецца толькі зменай значэння table_prefix у wp-config.php; назвы табліц у базе дадзеных і некаторыя запісы usermeta таксама павінны быць абноўлены.

Таму, калі вы збіраецеся змяніць прэфікс табліц на існуючым жывым сайце, спачатку зрабіце поўную рэзервовую копію, па магчымасці пратэсціруйце аперацыю ў асяроддзі staging, а затым перанясіце на жывы сайт. Для новых усталёвак выкарыстанне нестандартнага прэфікса з самага пачатку больш бяспечнае і менш рызыкоўнае.

Магчымасць перамяшчэння wp-config.php за межы каранёвага каталога

У некаторых серверных канфігурацыях WordPress можа чытаць файл wp-config.php на адзін узровень вышэй за каранёвы каталог. Напрыклад, калі файлы WordPress знаходзяцца ў public_html, файл wp-config.php можна перамясціць у бацькоўскі каталог за межамі public_html. Гэты метад зніжае рызыку прамога доступу да файла праз web.

Аднак гэта можа не спрацаваць аднолькава ва ўсіх асяроддзях хостынгу. На віртуальным хостынгу перамясціць файл у бацькоўскі каталог можа быць немагчыма з-за правоў на дырэкторыі, структуры панэлі кіравання або палітык бяспекі. Акрамя таго, асобы, якія абслугоўваюць сайт, павінны ведаць месцазнаходжанне файла; у адваротным выпадку працэс адладкі ў будучыні можа зацягнуцца.

Перш чым прымяняць гэты метад, праверце файлавую структуру вашага хостынг-правайдэра. Калі вы карыстаецеся кіраваным WordPress-хостынгам, даведайцеся ў службы падтрымкі рэкамендаваную структуру каталогаў. Для правільнага кіравання каталогамі і правамі ў інфраструктуры Hostragons можа быць карысным змест Кіраўніцтва па панэлі кіравання хостынгам.

Узмацніце жорсткасць правоў на файлы і дазволаў на запіс

Бяспека wp-config.php залежыць не толькі ад канстантаў унутры яго, але і ад правоў доступу да файла на ўзроўні аперацыйнай сістэмы. Агульная рэкамендацыя: файл wp-config.php не павінен быць даступны для запісу ўсім. У большасці асяроддзяў хостынгу на базе Linux правы на файлы могуць быць настроены на больш абмежавальныя значэнні, такія як 400, 440 або 600. Якое значэнне будзе працаваць, залежыць ад карыстальніка сервера і мадэлі працы PHP.

Практычны падыход наступны: файл павінен захоўвацца з мінімальнымі правамі, якія не парушаюць працу сайта. Правы 777, якія дазваляюць запіс усім, катэгарычна не павінны выкарыстоўвацца. 644 можа працаваць па змаўчанні ў некаторых асяроддзях, але для больш адчувальных усталёвак лепш аддаць перавагу 600 або 440. Пасля змены правоў неабходна праверыць загрузку сайта, панэль кіравання і экраны абнаўлення плагінаў.

Акрамя таго, важна блакаваць доступ да файла wp-config.php на ўзроўні вэб-сервера. У сучасных інфраструктурах хостынгу PHP-файлы не адлюстроўваюцца непасрэдна як зыходны код; аднак на няправільна наладжаных серверах можа ўзнікнуць рызыка. Таму надзейная інфраструктура хостынгу гэтак жа важная, як і правы на файлы.

Кіруйце аўтаматычнымі абнаўленнямі з арыентацыяй на бяспеку

Ядро WordPress, плагіны і тэмы рэгулярна атрымліваюць абнаўленні бяспекі. Праз wp-config.php можна ў пэўнай ступені кіраваць паводзінамі аўтаматычных абнаўленняў. З пункту гледжання бяспекі звычайна рэкамендуецца аўтаматычнае ўжыванне мінорных абнаўленняў. Таму што гэтыя абнаўленні ў асноўным накіраваны на бяспеку і выпраўленне памылак.

Напрыклад, калі пакінуць уключанымі мінорныя абнаўленні ядра WordPress, гэта памяншае затрымку ў рэагаванні на вядомыя ўразлівасці. Аднак пераход на новыя мажорныя версіі можа патрабаваць тэсціравання на сумяшчальнасць з тэмай і плагінамі. Таму для карпаратыўных сайтаў самы надзейны метад — трымаць аўтаматычныя патчы бяспекі ўключанымі, а буйныя абнаўленні прымяняць на жывым сайце толькі пасля тэсціравання ў асяроддзі staging.

У стратэгіі абнаўлення можна выкарыстоўваць тры асноўныя правілы: спачатку рэзервовая копія, потым тэст, і толькі ў канцы — прымяненне на жывым сайце. Гэтая простая паслядоўнасць забяспечвае правільны баланс паміж бяспекай і бесперапыннасцю працы.

Трымайце пад кантролем ліміт памяці PHP і спажыванне рэсурсаў

У файле wp-config.php можна вызначыць аб'ём памяці, даступны для WordPress, з дапамогай значэнняў WP_MEMORY_LIMIT і WP_MAX_MEMORY_LIMIT. Хоць гэтыя налады не выглядаюць як прамыя налады бяспекі, яны важныя пры атаках на спажыванне рэсурсаў, збойных плагінах і інтэнсіўных адміністрацыйных аперацыях.

Напрыклад, для невялікага блога часцей за ўсё дастаткова 128M, у той час як для крамаў на WooCommerce або шматмоўных сайтаў можа спатрэбіцца 256M. Аднак неапраўданае павелічэнне ліміту памяці можа прывесці да таго, што збойны плагін будзе спажываць яшчэ больш рэсурсаў і знізіць прадукцыйнасць сервера. Правільнае значэнне павінна ацэньвацца з улікам трафіку сайта, колькасці плагінаў і рэсурсаў тарыфнага плана хостынгу.

Калі вы часта сутыкаецеся з памылкамі памяці, замест таго каб проста павялічваць ліміт, даследуйце крыніцу праблемы. Прычынай могуць быць цяжкія плагіны, неаптымізаваныя запыты, састарэлая версія PHP або недастатковы тарыфны план хостынгу. Прадукцыйнасць і бяспека павінны разглядацца разам. У гэтым кантэксце змест Аптымізацыя прадукцыйнасці WordPress і Пакеты хостынга з высокай прадукцыйнасцю дае натуральную магчымасць для спасылак.

Забяспечце бяспеку дырэкторыі часовых файлаў і паводзін пры загрузцы

У некаторых асяроддзях хостынгу WordPress захоўвае часовыя файлы ў сістэмных каталогах па змаўчанні. Гэта нармальна; аднак агульныя каталогі з няправільна настроенымі правамі могуць ствараць рызыку для бяспекі. Праз вызначэнне WP_TEMP_DIR у wp-config.php можна паказаць каталог, які WordPress будзе выкарыстоўваць для часовых файлаў.

Калі вы збіраецеся выкарыстоўваць гэты метад, пераканайцеся, што каталог зачынены для публічнага доступу, мае кантраляваны дазвол на запіс і даступны толькі карыстальніку, звязанаму з гэтым сайтам. Часовыя каталогі актыўна выкарыстоўваюцца, асабліва падчас загрузкі файлаў, апрацоўкі медыя і абнаўлення плагінаў. Няправільна наладжаны часовы каталог можа выклікаць памылкі загрузкі або рызыку ўцечкі файлаў.

Бяспека дамена cookies і мультысайтавасці

У праектах, якія выкарыстоўваюць мультысайтавасць WordPress, паддамены або структуру падкаталогаў, значэнні дамена cookies і URL-адрасоў сайта становяцца больш адчувальнымі. Няправільнае вызначэнне дамена cookies можа прывесці да таго, што сесіі будуць сапраўднымі для нечаканых паддаменаў, або да цыклаў уваходу. З пункту гледжання бяспекі, для кожнай архітэктуры сайта вобласць дзеяння cookies павінна быць абмежаваная мінімальна неабходным даменам.

Напрыклад, у структурах кшталту admin.example.com, shop.example.com і blog.example.com трэба ўсвядомлена вызначаць, ці будуць cookies сапраўднымі для ўсіх паддаменаў, ці толькі для канкрэтнага дамена. Празмерна шырокая вобласць дзеяння cookies можа павялічыць верагоднасць таго, што ўразлівасць на адным паддамене паўплывае на сесіі ў іншых.

Калі вы выкарыстоўваеце мультысайтавасць, ацэньвайце мультысайтавыя канстанты ў wp-config.php, налады мапінгу даменаў і канфігурацыю SSL разам. У такіх праектах планаванне даменаў і SSL таксама важнае. Спасылкі Кіраванне некалькіх даменаў і сертыфікат SSL wildcard могуць быць тут дарэчы.

Кантрольны спіс бяспекі для wp-config.php

Вы можаце перыядычна правяраць ніжэйпрыведзены спіс на вашым жывым сайце WordPress. Гэта добрая звычка — праглядаць яго асабліва пасля ўстаноўкі новых плагінаў, змены тэмы, пераносу сервера і падазроных спробаў уваходу.

• Ці захоўваецца актуальная копія wp-config.php ў надзейным месцы?
• Ці з'яўляюцца ключы бяспекі і значэнні "соляў" унікальнымі і выпадковымі?
• Ці актыўная дырэктыва DISALLOW_FILE_EDIT?
• Ці адключаны WP_DEBUG на жывым сайце або ці знаходзіцца ён у рэжыме бяспечнага лагавання?
• Ці працуе панэль кіравання абавязкова праз HTTPS?
• Ці не мае карыстальнік базы дадзеных залішніх прывілеяў?
• Ці адрозніваецца прэфікс табліц ад стандартнага wp_ на новых усталёўках?
• Ці не ўтрымліваюць правы на файлы небяспечных значэнняў, такіх як 777?
• Ці ўключаны аўтаматычныя абнаўленні бяспекі кантраляваным чынам?
• Ці правільна наладжаны SFTP, рэзервовае капіраванне і SSL ва ўліковым запісе хостынгу?

Частыя памылкі і спосабы іх пазбегнуць

Самая распаўсюджаная памылка пры працы з wp-config.php — дадаваць знойдзеныя ў інтэрнэце фрагменты кода, не разумеючы іх прызначэння. Не кожны сайт на WordPress мае аднолькавую структуру сервера, тэмы, плагінаў і трафіку. Таму налада, якая без праблем працуе на адным сайце, можа выклікаць праблемы з сесіямі або памылку абнаўлення на іншым.

Другая распаўсюджаная памылка — пакідаць адладкавую інфармацыю ўключанай на жывым сайце. Гэта не толькі псуе карыстальніцкі досвед, але і прыводзіць да ўцечкі тэхнічнай інфармацыі. Трэцяя памылка — пакідаць рэзервовую копію wp-config.php у вэб-каранёвым каталогу пад назвамі кшталту wp-config-backup.php, wp-config-old.php. Пры няправільных наладах сервера гэтыя файлы могуць быць спампаваныя як просты тэкст. Рэзервовыя копіі павінны захоўвацца ў месцы, недаступным для вэб-доступу.

Чацвёртая памылка — усталёўваць правы на файлы 777 для вырашэння праблемы, а потым не вяртаць іх назад. Хоць гэта можа здацца хуткім рашэннем, з пункту гледжання бяспекі гэта вельмі небяспечна. Пятая памылка — актываваць FORCE_SSL_ADMIN без усталяванага SSL; гэта можа выклікаць праблемы з доступам да панэлі кіравання.

Як пабудаваць прафесійны ўзровень бяспекі WordPress?

Умацаванне wp-config.php — важны крок, але сам па сабе ён не забяспечвае поўнай бяспекі. Прафесійны падыход да бяспекі павінен быць шматузроўневым. Надзейная ізаляцыя хостынгу, актуальная версія PHP, міжсеткавы экран для вэб-прыкладанняў (WAF), надзейны SSL, рэгулярнае рэзервовае капіраванне, абмежаваная колькасць адміністрацыйных уліковых запісаў, двухфактарная аўтэнтыфікацыя і маніторынг логаў — усё гэта павінна разглядацца ў комплексе.

Напрыклад, калі зламыснік спрабуе выкарыстаць уразлівасць плагіна, узровень WAF можа заблакаваць запыт. Калі пароль карыстальніка скрадзены, уключаецца двухфактарная праверка. Калі файл быў зменены, можна хутка аднавіцца з рэзервовай копіі. А wp-config.php у гэтым ланцужку з'яўляецца крытычнай кропкай канфігурацыі і абмежавання.

Калі вы ствараеце новы сайт на WordPress, з самага пачатку рухайцеся з арыентацыяй на бяспеку: сплануйце надзейны дамен і SSL, выберыце бяспечны хостынг, змяніце стандартны прэфікс табліц, згенеруйце унікальныя ключы "соляў", адключыце рэдагаванне файлаў праз панэль і актывуйце рэгулярныя рэзервовыя копіі. Гэтыя базавыя крокі прадухіляць мноства праблем у будучыні, не даўшы ім пачацца.

Заключэнне: Малыя налады — вялікі эфект для бяспекі

Пашыраныя налады бяспекі, даступныя праз файл wp-config.php, прапануюць практычныя і эфектыўныя меры, якія памяншаюць паверхню нападу вашага сайта. Абнаўленне ключоў "соляў", адключэнне рэдагавання файлаў, утойванне адладкавай інфармацыі, прымусовае выкарыстанне SSL, абмежаванне прывілеяў базы дадзеных і ўзмацненне жорсткасці правоў на файлы — гэта крокі, якія прыносяць вялікую карысць большасці сайтаў на WordPress.

Не спяшайцеся пры ўжыванні гэтых налад: зрабіце рэзервовую копію, уносьце змены па адной і тэсціруйце кожны крок. Бяспечная канфігурацыя ў спалучэнні з правільнай інфраструктурай хостынгу і рэгулярным абслугоўваннем робіць ваш сайт на WordPress значна больш устойлівым. Калі вы плануеце больш бяспечную і стабільную інфраструктуру, вы можаце вывучыць рашэнні Hostragons хостынг WordPress, Сертыфікат SSL і Рэгістрацыя дамена, каб знайсці аптымальны адпраўны пункт для вашых патрэб.

Часта задаваныя пытанні

Ці бяспечна рэдагаваць файл wp-config.php?

Так, гэта бяспечна, калі вы робіце гэта правільна: ствараеце рэзервовыя копіі і ўносіце змены кантралявана. Аднак адна адзіная сінтаксічная памылка можа паўплываць на доступ да сайта. Таму спачатку зрабіце рэзервовую копію файлаў і базы дадзеных, затым прымяняйце і тэсціруйце налады па адной.

Што адбудзецца, калі я змяню ключы "соляў" у wp-config.php?

Усе актыўныя сесіі карыстальнікаў будуць завершаны, і ім спатрэбіцца ўвайсці зноў. Гэтая аперацыя не выдаляе кантэнт і не пашкоджвае базу дадзеных. Гэта хуткая мера, якая асабліва рэкамендуецца пасля падазронага ўваходу, рызыкі для адміністрацыйнага ўліковага запісу або парушэння бяспекі.

Ці павінен WP_DEBUG заставацца ўключаным на жывым сайце?

Не. Калі WP_DEBUG уключаны на жывым сайце, паведамленні пра памылкі могуць раскрыць наведвальнікам тэхнічную інфармацыю. Бяспечны падыход — не паказваць памылкі на экране і выкарыстоўваць кантраляванае лагаванне толькі для кароткачасовых патрэб.

Ці перашкаджае DISALLOW_FILE_EDIT абнаўленню плагінаў і тэм?

Не, DISALLOW_FILE_EDIT адключае толькі файлавы рэдактар у панэлі кіравання. Абнаўленні плагінаў і тэм працягваюцца ў звычайным рэжыме. Каб адключыць і абнаўленні, патрабуюцца іншыя, больш абмежавальныя налады.

Якімі павінны быць правы доступу да файла wp-config.php?

Хоць гэта залежыць ад канфігурацыі сервера, мэта складаецца ў тым, каб захоўваць файл з мінімальнымі правамі, якія не парушаюць працу. 777 не павінны выкарыстоўвацца ні ў якім разе. У большасці асяроддзяў могуць працаваць 600, 440 або 644; пасля змены неабходна праверыць сайт і панэль кіравання.