Вход в системата: пароли, двуфакторно удостоверяване и brute force

Модул 7: Сигурност · Време за четене: 9 минути

Учебна цел: След този урок ще можете да защитите входа на Вашия сайт със силни пароли, двуфакторно удостоверяване и ограничаване на опитите за вход, и ще знаете какво е xmlrpc.php.

Ключови понятия: мениджър на пароли, парола фраза, уникална парола, двуфакторно удостоверяване (2FA, TOTP), passkey, brute force, ограничаване на опитите за вход, wp-login.php само за определен IP адрес, xmlrpc.php, изтичане на потребителски имена (REST, ?author=), пароли за приложения

Паролата: дълга и уникална

Добрата парола има две характеристики:

1. Дълга: дължината е по-важна от странните символи. Парола фраза от четири или пет случайни думи (zeef-pinguin-oktober-lantaarn) е по-силна и по-лесна за запомняне от W8w00rd!. Нидерландската правителствена кампания Veilig Internetten препоръчва уникална парола от минимум 12 символа, за предпочитане парола фраза.
2. Уникална: да не се използва никъде другаде. Credential stuffing (урок 7.1) работи само ако повторно използвате парола.

Никой не помни десетки дълги уникални пароли. Затова използвайте мениджър на пароли: програма, която ги създава, съхранява и попълва вместо Вас. Така трябва да запомните само една парола, тази на самия мениджър, която също защитавате с двуфакторно удостоверяване.

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

Двуфакторно удостоверяване

С двуфакторно удостоверяване (2FA) при вход, освен паролата, Ви е нужно още нещо: обикновено шестцифрен код от приложение на телефона Ви (authenticator, по стандарта TOTP). Нарушител, който знае паролата Ви, все пак не може да влезе.

WordPress няма вградено двуфакторно удостоверяване. Добавяте го с разширение. Има много такива; едно просто е Two Factor, създадено от сътрудници на самия WordPress. Разширенията за сигурност също често го включват. При избор обърнете внимание на:

• TOTP приложения и резервни кодове (за случаите, когато изгубите телефона си); кодовете по имейл са по-слаби, защото пощенската Ви кутия също може да бъде хакната;
• възможност да се направи задължително за администратори и редактори;
• passkeys: вход с пръстов отпечатък, лице или ключ за сигурност, без парола. За това също има разширения. Passkeys са устойчиви на фишинг, защото работят само на истинския сайт.

Включете двуфакторно удостоверяване и за всичко около Вашия сайт: Вашия хостинг панел, имейл, регистратор и мениджър на пароли. Нарушител, който поеме контрол над хостинг панела Ви, няма нужда от паролата Ви за WordPress.

Brute force и ограничаване на опитите за вход

Отворен WordPress сайт получава опити за вход в wp-login.php по цял ден, често с admin и списъци с често използвани пароли. С дълга парола и 2FA те не успяват да влязат, но всеки опит струва изчислителен ресурс на сървъра Ви (пълно зареждане на WordPress). При голяма вълна сайтът Ви забавя.

Самият WordPress не ограничава броя опити. Какво помага, подредено от „спиране най-рано“:

1. На сървъра: много доставчици на хостинг блокират IP адрес, който прави много неуспешни опити за кратко време, още преди WordPress да се стартира (с firewall или функция на уеб сървъра). Попитайте Вашия доставчик какво се случва.
2. wp-login.php само за Вашия IP адрес: с няколко реда в .htaccess (при LiteSpeed и Apache):

<Files wp-login.php>
Require ip 192.0.2.10
</Files>

Това работи добре, ако имате постоянен IP адрес. Ако нямате такъв (вкъщи, на телефона), ще заключите себе си, когато адресът Ви се промени. Алтернатива е допълнителна парола на страницата за вход (т.нар. „защитена папка“, basic authentication) с различна парола от Вашата парола за WordPress.

3. Разширение, което ограничава опитите: след пет неуспешни опита IP адресът е блокиран за известно време. Работи, но едва след като WordPress вече е стартирал, така че изчислителният разход остава.

Преименуването или скриването на страницата за вход (например /моят-вход вместо /wp-login.php) намалява шума в логовете Ви. Това не е истинска сигурност и някои разширения и теми очакват стандартния адрес. Добре е като допълнение, но никога вместо добра парола и 2FA.

xmlrpc.php

xmlrpc.php е стара връзка от времето преди REST API, чрез която приложения и други сайтове комуникират с WordPress. Все още се използва от някои приложения, от Jetpack и от няколко интеграции. За повечето сайтове той е излишен.

Нарушителите обичат xmlrpc.php, защото с една заявка може да се изпробват стотици пароли едновременно (с функцията system.multicall), и защото може да се злоупотреби за атаки срещу други сайтове (pingbacks). Какво да направите:

• Не го използвате: блокирайте го. Някои доставчици на хостинг, включително WebOké, блокират xmlrpc.php по подразбиране на сървъра. Иначе с правило в .htaccess или с разширение за сигурност.
• Използвате го (например за приложение, което има нужда от него): оставете го отворен, но осигурете силни пароли, 2FA и ограничаване на опитите. Съвременните приложения обикновено използват REST API с парола за приложение (урок 3.3).

Потребителски имена, които изтичат

В урок 3.3 видяхте, че WordPress показва производна на потребителските имена:

• https://example.com/?author=1 пренасочва към /author/<name>/;
• https://example.com/wp-json/wp/v2/users показва списък с идентификатори (slugs) на всички, които са публикували нещо.

Проблем ли е това? Потребителското име не е парола. С дълга уникална парола и 2FA това има малко значение. Но то дава на нарушителя половината от данните за вход и улеснява целенасочения фишинг. Разумни мерки:

• дайте на администраторите потребителско име, различно от публичното им име, и не публикувайте с администраторски акаунт (урок 3.3);
• ограничете списъка с потребители в REST API с разширение за сигурност или няколко реда код, ако нямате нужда от него. Не затваряйте изцяло REST API: блоковият редактор и много разширения имат нужда от него.

Пароли за приложения

Паролите за приложения (урок 3.3) са сигурен начин да дадете достъп на приложение или система, но те заобикалят двуфакторното Ви удостоверяване: приложение с парола за приложение няма нужда от код. Създавайте ги само когато е необходимо, за акаунт с ниска роля, и ги отменяйте, когато вече не използвате връзката.

Обобщение

• Използвайте дълги, уникални пароли (парола фрази) в мениджър на пароли.
• Включете двуфакторно удостоверяване, с разширение в WordPress, а също и на хостинг панела, имейла и регистратора си.
• Спирайте опитите за вход възможно най-рано: на сървъра, с IP правило или допълнителна парола, или с разширение.
• Блокирайте xmlrpc.php, ако не го използвате.
• Изтеклите потребителски имена не са катастрофа, но са сигнал: не публикувайте като администратор и ограничете списъка с потребители в REST, ако нямате нужда от него.

Тест

Задача

Задача A7.3: Какво разкрива Вашият сайт при вход? Въведете адреса на Вашия сайт и докажете, че е Ваш собствен (с кода на задачата, като TXT запис или като файл). Програмата проверява три неща: дали xmlrpc.php връща списък с функции (отворен) или е блокиран, дали /wp-json/wp/v2/users показва потребителски имена (slugs), и къде пренасочва /?author=1. Посочете дали имате нужда от xmlrpc.php; ако не, отворен xmlrpc.php е червено. Изтеклите slugs са оранжево с обяснение.

Задача D7.3: Включване на двуфакторно удостоверяване. Включете двуфакторно удостоверяване за всички администратори на Вашия WordPress сайт, а също и на Вашия хостинг панел и имейл. Запазете резервните кодове в мениджъра на пароли. Отбележете за всеки елемент, че е включен, и запишете кой метод използвате (приложение, passkey, имейл) и къде се съхраняват резервните кодове. Запишете също как допълнително защитавате wp-login.php и защо избрахте този начин.

Допълнително четене

Тези статии описват стъпките в панелите на WebOké; в други панели работят по подобен начин.

• Ръководство за DirectAdmin 3.7: Сигурни пароли и какво да правите при изтекла парола
• Двустъпково удостоверяване в Моят WebOké и настройване на приложение за удостоверяване (authenticator)
• Няма достъп до xmlrpc.php в WordPress
• Защита на wp-login.php в WordPress
• Ръководство за DirectAdmin 15.9: Защитени с парола директории
• Veilig inloggen (Veilig Internetten, нидерландското правителство): https://veiliginternetten.nl/veilig-inloggen/
• Brute force атаки (developer.wordpress.org, на английски): https://developer.wordpress.org/advanced-administration/security/brute-force/