Какво не трябва да правите

Модул 10: Безопасност в дългосрочен план · Време за четене: 12 минути

Цел на урока: След този урок ще разпознавате грешките, които най-често водят до хакнат или повреден сървър, ще можете да обясните защо са опасни и ще знаете какво да правите вместо това.

Основни понятия: вход като root с парола, слаба или стандартна парола, отворена база данни, Docker API на порт 2375, docker.sock в контейнер, chmod 777, curl | bash, тайни в Git, административен панел без двуфакторно удостоверяване, защитна стена, изключена „само за малко“, без актуализации, без резервно копие

Защо урок за грешките?

Повечето сървъри не се хакват от гениален нападател с неизвестна уязвимост. Хакват се от ботове, които обхождат целия интернет в търсене на известни грешки: парола, която може да се познае, отворена база данни, програма, на която от месеци липсва актуализация. Който избягва грешките от този урок, престава да бъде цел за тези ботове. Това е най-голямата част от защитата, която можете да постигнете.

За всяка грешка е обяснено защо е опасна и какво да правите вместо това. Почти всичко сте научили в предишните уроци; този урок го събира на едно място.

1. Вход като root с парола

Проблемът. Всеки сървър получава опити за вход по цял ден на root (урок 5.3). Ако root може да влиза с парола, тази парола е единственото, което стои между бота и пълния контрол. Повторно използвани или твърде къси пароли рано или късно се отгатват или вече фигурират в изтекъл списък.

Направете това. Вход само с ключове: PasswordAuthentication no и KbdInteractiveAuthentication no, root най-много с ключ (PermitRootLogin prohibit-password) или изобщо не (no), а ежедневната работа като обикновен потребител със sudo (уроци 2.2 и 3.2). Проверете отвън какви методи за вход предлага Вашият сървър (задача Z2.2).

2. База данни, кеш или клъстер за търсене, отворени към интернет

Проблемът. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch или OpenSearch (9200) и MongoDB (27017) са създадени за доверени програми в доверена мрежа. Ако слушат на 0.0.0.0 без защитна стена, скенерите бързо ги откриват. Самата документация на Redis посочва, че той не бива да бъде изложен на интернет и че всеки с достъп може да изтрие целия набор от данни; чрез командата CONFIG нападателят може дори да записва файлове на сървъра. Отворените бази данни и клъстери за търсене от години са известна причина за големи изтичания на данни и за съобщения с искане за „откуп“ на мястото на Вашите данни.

Направете това. Оставете такива услуги да слушат на 127.0.0.1 (урок 5.1), дръжте ги зад защитната стена (урок 5.2) и в Docker не ги публикувайте или ги публикувайте само на 127.0.0.1 (урок 9.3). Ако сами имате нужда от достъп от лаптопа си: използвайте SSH тунел (урок 2.3). Проверете отвън (задача Z5.1).

3. Отворен Docker API или docker.sock в контейнер

Проблемът. Който може да управлява Docker демона, на практика е root на сървъра: документацията на Docker посочва, че само доверени потребители бива да управляват демона, и приравнява достъпа до демона на root достъп. Две разновидности на тази грешка:

• Демонът слуша на TCP порт без TLS (обичайно 2375). Всеки, който достигне до този порт, може да стартира контейнери с монтиран диск на Вашия сървър.
• На контейнер се подава /var/run/docker.sock като volume („така той сам ще може да управлява контейнери“). Ако този контейнер бъде хакнат, целият сървър е загубен.

Групата docker също е равностойна на root (урок 9.2): добавяйте в нея само администратори.

Направете това. Оставете Docker да работи само през локалния socket. Отдалеченото управление става през SSH (docker context с ssh://), а ако наистина трябва да е през TCP, с TLS на порт 2376 и клиентски сертификати. Монтирайте docker.sock само в контейнер, на който имате пълно доверие и от който наистина се нуждаете, и за предпочитане само за четене чрез ограничаващ proxy.

4. chmod 777, за да изчезне съобщението за грешка

Проблемът. „Permission denied“ при качване на файл, а някой форум казва: chmod -R 777 /var/www. След това всеки потребител и всеки процес на сървъра може да записва каквото и да е в Вашия сайт, включително хакнат plugin или друг акаунт. Код, в който уеб сървърът може да записва, може чрез уязвимост да бъде заменен с backdoor.

Направете това. Изяснете кой трябва да записва и къде (урок 3.1): обикновено само потребителят на уеб сървъра, в една папка за качвания или кеш. Кодът да има собственик, различен от уеб сървъра, с права 644/755, а качванията 750/640 или подобни.

5. curl ... | bash и софтуер от къде ли не

Проблемът. Скрипт, който изпълнявате като root, без да сте го прегледали, може всичко: да добавя източници и ключове, да презаписва файлове, да отвори услуга. Дори намерението да е добро, след това не знаете какво е променено, а при следващото надграждане на версията нещо се чупи (урок 4.3).

Направете това. Изтеглете скрипта и го прочетете. За предпочитане инсталирайте от хранилището на Вашата дистрибуция или от официалния източник на производителя, със собствен ключ (Signed-By, урок 4.1). Записвайте какво инсталирате и защо.

6. Без актуализации или актуализации „по-късно“

Проблемът. Уязвимостите се отстраняват и след това се използват за атаки, често в рамките на дни. Сървър, който месеци наред не получава актуализации или работи на версия без поддръжка, има списък с известни пролуки. Контейнерите не се актуализират от apt.

Направете това. Включете автоматичните актуализации за сигурност (урок 4.2), определете постоянен момент за рестартиране, запишете крайната дата на поддръжка на Вашата версия в календара си (урок 4.3) и редовно актуализирайте контейнерите (урок 9.4).

7. Без резервно копие или с резервно копие, което никога не е тествано

Проблемът. Snapshot на същото хранилище не е резервно копие (урок 8.1). Резервно копие, което се намира на самия сървър, изчезва заедно с него при хак или ransomware. А резервно копие, което никога не е възстановявано, е надежда, а не сигурност.

Направете това. Криптирани резервни копия извън сървъра (restic, урок 8.2), наблюдение дали се изпълняват и тест за възстановяване поне веднъж на тримесечие.

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

Проблемът. Административен панел за база данни (например phpMyAdmin), за Docker (например Portainer), за Вашето приложение или за Вашия трезор за пароли е привлекателна цел: една парола дава достъп до всичко. Стандартни пароли като admin/admin и регистрация, оставена отворена (Vaultwarden, урок 9.4), правят нещата още по-лесни.

Направете това. Не отваряйте административните панели към интернет: достъпвайте ги през SSH тунел или само от фиксиран адрес. Ако панелът все пак трябва да е публичен: https, силна уникална парола от Вашия мениджър на пароли, двуфакторно удостоверяване и затворена регистрация. Винаги сменяйте стандартните пароли.

9. Тайни в Git или в compose файла

Проблемът. Парола, API ключ или private key във файл, който попада в Git хранилище, остава там завинаги в историята, дори ако по-късно го премахнете. Публичните хранилища се претърсват от ботове точно за такива ключове.

Направете това. Пазете тайните в отделен файл с права 600 (EnvironmentFile, урок 6.3; .env при Docker Compose, урок 9.3), който е посочен в .gitignore. Ако все пак е изтекла тайна: веднага я сменете (нова парола, нов ключ); само почистването в Git не е достатъчно.

10. Защитната стена изключена „за малко“, всичко като root и никакви бележки

Проблемът. „Ще изключа защитната стена за малко, за да тествам“ се забравя. „Ще го направя набързо като root“ се превръща в навик. А сървър, за който никой не знае какво работи на него и защо, не може да се управлява или възстановява.

Направете това. Тествайте с временно, тясно правило (един порт, един адрес на източника) и след това го премахнете. Работете като обикновен потребител със sudo. Водете кратко досие на сървъра: какво работи, кои портове са отворени, къде са резервните копия, кога е крайната дата на поддръжка на версията (урок 10.4).

На практика

Всички тези грешки могат да се допуснат на всеки VPS, при WebOké точно както и при други доставчици: за това, което се случва във Вашия сървър, отговаряте Вие. Доставчикът обаче може да изключи сървър от мрежата, ако изпраща спам или извършва атаки, защото това засяга други клиенти. Затова превенцията е важна и за Вашата собствена достъпност.

Обобщение

• Повечето хакове използват известни грешки, а не неизвестни уязвимости.
• Вход с ключове, входът с парола изключен; базите данни, кешовете и Docker API никога отворени към интернет; без docker.sock в контейнери, на които нямате пълно доверие.
• Без chmod 777 и без curl | bash: знайте кой какво може и какво инсталирате.
• Автоматични актуализации, резервни копия извън сървъра и тествани, административни панели зад тунел или с двуфакторно удостоверяване.
• Тайните извън Git и извън compose файловете; изтекла тайна означава сменена тайна.

Тест (quiz)

Задача

Задача Z10.2: Коя е грешката? В примерния файл casussen-z10-2.md има осем кратки казуса на сървъри, при които нещо не е наред. За всеки казус изберете коя е грешката от списъка в този урок (от A до J) и коя е най-добрата първа стъпка. Програмата сравнява с фиксирания ключ и след това показва обяснението за всеки казус.

Още за четене

• Защита на VPS: първите пет минути
• Мениджър на пароли и passkeys: така организирате сигурно Вашето влизане
• Документация на Docker, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
• Документация на Docker, Protect the Docker daemon socket: https://docs.docker.com/engine/security/protect-access/
• Redis, Security: https://redis.io/docs/latest/operate/oss_and_stack/management/security/