Защита на админ входовете от brute force: защита от brute force за всеки вход

Накратко: Ефективната защита от brute force за вход се състои от няколко слоя: двуфакторно удостоверяване за всички администратори, ограничител на опитите за влизане в уеб сървъра, автоматични блокировки на мрежово ниво и сигурно съхранение на паролите в кода. Където е възможно, административната зона допълнително е достъпна само от известни мрежи.

Как протичат brute force атаките срещу входове

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

Три варианта са разпространени. При класическия brute force се изпробват много пароли срещу един акаунт. При Password Spraying една често срещана парола се тества срещу много акаунти, за да се заобиколят блокировките. При Credential Stuffing се използват данни за достъп, откраднати от други услуги.

За ръководството и собствениците положението се обобщава лесно: превзет администраторски акаунт е толкова опасен, колкото уязвимост в сървъра. Който е администратор, може да инсталира разширения, да променя код и да експортира данни.

Такива атаки се разпознават по струпване на неуспешни влизания, по POST заявки към адреса за вход от много различни IP адреси и по опити за влизане с потребителски имена като „admin“ или имена от импресума. Осезаемо по-високо натоварване на сървъра в необичайно време също може да сочи към това, защото всяко влизане струва изчислително време за проверка на паролата.

Защита от brute force при вход: най-ефективните мерки

Не всяка мярка пасва на всяка система. Следният ред се е доказал, защото първите точки съчетават най-много ефект с малко усилия:

• Двуфакторно удостоверяване за всички акаунти с администраторски права. Дори позната парола тогава не е достатъчна. Подробности има в наръчника Двуфакторно удостоверяване за административни достъпи.
• Уникални, дълги пароли от мениджър на пароли, никакви споделени акаунти.
• Rate limiting в уеб сървъра, така че на адрес да са възможни само няколко опита в минута.
• Автоматични блокировки на многократно подозрителни адреси на мрежово ниво, например с Fail2ban.
• Свиване на административната зона: достъп само от фирмената мрежа или през VPN, ненужните интерфейси да се изключат.
• Еднакви съобщения за грешка, които не издават дали потребителското име съществува.
• Наблюдение на неуспешните влизания и известяване при отклонения.

Rate limiting в уеб сървъра

С Nginx броят на заявките към адрес за вход може да се ограничи за всеки IP адрес. Примерът показва страница за вход на WordPress; пътя и предаването към PHP адаптирайте към Вашата система.

# в http блока
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# в server блока
location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    # тук включете обичайното предаване към PHP на Вашия сървър
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

При Apache ограничаването на административната зона до известни адреси предлага проста, ефективна защита:

<Location "/admin">
    Require ip 192.0.2.0/24
</Location>

Адресът 192.0.2.0/24 е заместител от областта за документация; въведете Вашата фирмена мрежа или адреса на Вашия VPN. Ако уебсайтът Ви е зад прокси или CDN, сървърът трябва да познава истинския адрес на посетителя, иначе правилото няма да действа както се желае.

Fail2ban и блокировки на мрежово ниво

Fail2ban чете лог файлове и блокира адреси, които многократно привличат внимание, за определено време във firewall-а. За rate limiting на Nginx Fail2ban вече носи подходящ филтър:

# /etc/fail2ban/jail.local
[nginx-limit-req]
enabled  = true
port     = http,https
logpath  = /var/log/nginx/error.log
maxretry = 10
findtime = 10m
bantime  = 1h

[sshd]
enabled  = true
maxretry = 5
bantime  = 1h

След рестарта проверете с fail2ban-client status дали jail-овете са активни. Погрижете се Вашите собствени постоянни адреси да бъдат изключени чрез ignoreip, за да не заключите сами себе си. За страниците за вход на отделни CMS са възможни собствени филтри, но те трябва да пасват на действителния формат на лога и да се тестват предварително.

Ако пред сървъра има CDN или прокси, Fail2ban без допълнителни настройки вижда само неговите адреси. Блокировка тогава би засегнала всички посетители. В този случай уеб сървърът трябва да вземе истинския адрес на посетителя от хедъра на предходната услуга, а блокировките се поставят по-добре директно при CDN.

Блокировките на мрежово ниво са инструмент срещу масови атаки, не срещу целенасочени. Разпределени атаки от много адреси с малко опити на адрес подкопават всеки праг. Затова вторият фактор остава най-важният слой, а Fail2ban намалява преди всичко натоварването и шума в логовете.

Правилно съхранение на пароли в собствен софтуер

Който програмира собствени входове, не бива да съхранява пароли в чист текст или с бързи хеш функции като MD5 или SHA-1. PHP носи със password_hash() сигурно решение, което управлява автоматично salt и алгоритъма.

<?php
declare(strict_types=1);

// При регистрация или смяна на парола
$hash = password_hash($passwort, PASSWORD_DEFAULT);

// При влизане
if (password_verify($eingabe, $hashAusDatenbank)) {
    if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
        $neu = password_hash($eingabe, PASSWORD_DEFAULT);
        // $neu да се запише в базата данни
    }
    // Влизането е успешно, ID на сесията да се поднови
} else {
    usleep(random_int(200000, 400000)); // равномерно време за отговор
    // да се изведе еднакво съобщение за грешка
}

password_needs_rehash() гарантира, че по-старите хешове при следващото влизане автоматично се преминават към актуалния алгоритъм. Неуспешните опити протоколирайте с време, акаунт и адрес, за да се забелязват модели. Указания за анализа има в наръчника Анализ на логовете на уеб сървъра след атака.

Особености при CMS, магазини и панели

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

• WordPress: Интерфейсът xmlrpc.php също приема влизания. Ако не е нужен, например за по-стари приложения, заключете го в уеб сървъра. Проверете освен това дали потребителски имена са видими през страниците на авторите или REST интерфейса и използвайте за администратори имена, които не се появяват публично.
• Магазини: Освен административната зона цел са и клиентските акаунти, особено за Credential Stuffing. Тук помагат rate limiting, известия при нови влизания и по избор втори фактор за клиентите.
• Хостинг панели и уеб поща: Тези интерфейси често са достъпни от целия свят и защитават целия сървър. Те трябва да са достъпни само от известни мрежи или през VPN.
• SSH: Влизане с ключ вместо парола прави класическото налучкване безсмислено.

Какви защитни функции носи сама Вашата система, е посочено в документацията на производителя. Разширенията на трети доставчици трябва да се поддържат активно, иначе самите те стават риск. За операторите на WordPress страницата WordPress и PHP2Shell обобщава актуалните приоритети.

Как конкретно помага PHP SOS?

• Установяваме всички достъпни страници за вход на Вашите сървъри, от CMS до хостинг панела, и оценяваме тяхната защита.
• Въвеждаме rate limiting, Fail2ban и ограничения на достъпа в рамките на заздравяването на сървъра и ги тестваме.
• Подпомагаме въвеждането на двуфакторно удостоверяване за администратори и документираме аварийните достъпи.
• С мониторинг на сигурността държим непрекъснато под око грешните влизания и новите администраторски акаунти.

Често задавани въпроси

Източници

• OWASP Cheat Sheet Series (Authentication)
• BSI: Препоръки за сигурни пароли и двуфакторно удостоверяване
• OWASP Top 10