# Казуси към задача Z10.2 (курс VPS и администриране на Linux сървъри) За всеки казус изберете коя е грешката и коя е най-добрата първа стъпка. Всички имена и адреси са примерни. **Грешки (от урок 10.2):** A. Вход като root с парола B. База данни, кеш или клъстер за търсене, отворени към интернет C. Отворен Docker API или `docker.sock` в контейнер D. `chmod 777`, за да изчезне съобщение за грешка E. `curl ... | bash` и софтуер от където и да е F. Без актуализации или актуализации "по-късно" G. Без резервно копие или с резервно копие, което никога не е тествано H. Административен панел, отворен за всички, без двуфакторна проверка I. Тайни данни в Git или във Вашия compose файл J. "За малко" изключена защитна стена, всичко като root, без бележки --- **Казус 1.** На `web1.example.com` в `compose.yaml` при услугата `redis` е зададено: `ports: - "6379:6379"`. `ufw status` показва само 22, 80 и 443. Сканиране отвън открива отворен порт 6379. Първа стъпка: (a) рестартиране на ufw (b) премахване на правилото за порта или промяната му на `"127.0.0.1:6379:6379"` и повторно `docker compose up -d` (c) задаване на друг номер на порт за Redis (d) рестартиране на сървъра **Казус 2.** Разработчикът на уеб приложение на `app.example.net` съобщава, че качването на файлове не работело. Той го е "поправил" и сега всички файлове в `/var/www/app` са с `-rwxrwxrwx`. Първа стъпка: (a) да се остави така, сега работи (b) да се дадат на потребителя на уеб сървъра права за запис само в папката за качвания, а останалото да се върне на 644/755 с друг собственик (c) уеб сървърът да работи като root (d) изключване на AppArmor **Казус 3.** От вчера едно публично хранилище съдържа файл `.env` с `MAIL_API_KEY=...` от сървъра `web2.example.org`. Първа стъпка: (a) изтриване на файла от хранилището (b) отнемане на ключа в пощенската услуга и създаване на нов, както и добавяне на `.env` в `.gitignore` (c) преименуване на хранилището (d) да не се прави нищо **Казус 4.** `sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"` дава `permitrootlogin yes` и `passwordauthentication yes`. В журнала всяка минута има опити за вход като root. Първа стъпка: (a) инсталиране на fail2ban и нищо друго (b) поставяне на ключ за обикновен администратор със sudo, тестване и след това изключване на входа с парола и на входа като root с парола (c) преместване на SSH на порт 2222 (d) съхраняване на паролата на root в текстов файл **Казус 5.** `cat /etc/os-release` показва версия на Ubuntu, чиято стандартна поддръжка е приключила преди три години, без ESM. `apt list --upgradable` е празно. Първа стъпка: (a) да се радваме, няма актуализации (b) планиране на надграждане или нов сървър с поддържана LTS версия, със snapshot и резервно копие (c) преинсталиране на unattended-upgrades (d) рестартиране на сървъра **Казус 6.** Контейнерът `portainer` има volume `/var/run/docker.sock:/var/run/docker.sock` и е достъпен на `https://beheer.example.com` с паролата `admin123`, без двуфакторна проверка. Изберете грешката, която позволява най-големи щети, ако паролата бъде позната. Първа стъпка: (a) поставяне на панела зад SSH тунел или фиксиран адрес и задаване на силна парола с двуфакторна проверка (b) рестартиране на контейнера (c) избор на друг поддомейн (d) преинсталиране на Docker **Казус 7.** След неуспешна актуализация на базата данни се оказва, че единственото резервно копие е snapshot на два месеца, на същото хранилище като сървъра. Никой никога не е опитвал възстановяване. Първа стъпка за в бъдеще: (a) създаване на повече snapshots (b) настройване на криптирани резервни копия извън сървъра (например restic), с наблюдение и тест за възстановяване (c) базата данни повече никога да не се актуализира (d) втори диск в същия сървър **Казус 8.** На сървъра има `/usr/local/bin/tool` и непознат източник на пакети `extra.list` с опцията `[trusted=yes]`. Никой не знае откъде са дошли; предишният администратор инсталирал "всичко с един ред от някакъв уебсайт". Първа стъпка: (a) да се оставят, работи (b) да се изясни какви са източникът и програмата, източникът да се изключи с `trusted=yes` и занапред да се инсталира само от дистрибуцията или от официалния източник на създателя с `Signed-By` (c) рестартиране на сървъра (d) премахване на всички пакети За всеки казус попълнете: грешка (A-J) и първа стъпка (a-d).