Когато нещо се обърка

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

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

Основни понятия: инцидент, признаци, изолиране, snapshot като доказателство, дневник на инцидента, преинсталиране, смяна на ключове и пароли, чисто резервно копие, задължение за уведомяване при нарушение на сигурността на данните (72 часа), Комисията за защита на личните данни (КЗЛД), авариен план

Как да разпознаете инцидент

Пробивът рядко се обявява сам. Обикновено забелязвате нещо "странно". Признаци, които трябва да приемете сериозно:

• Високо натоварване без причина: процесорът е постоянно на 100%, например заради cryptominer. Проверете с top или htop кой е процесът и под кой потребител работи.
• Непознати процеси или услуги: програма със странно име, често в /tmp, /dev/shm или /var/tmp, или systemd услуга или таймер, които не сте създали Вие.
• Изходящ трафик, който не е нормален: доставчикът Ви съобщава, че сървърът Ви изпраща спам или атакува други сървъри, или графиките на мрежата в панела показват пикове.
• Нови потребители или ключове: ред в ~/.ssh/authorized_keys, който не познавате, потребител в /etc/passwd с UID 0, нов ред в /etc/sudoers.d/.
• Променени файлове: непознати PHP файлове в сайта Ви, променен crontab.
• Логове, които са изчезнали или са празни: нападателите обичат да заличават следите си.

Няколко команди за бърз оглед:

anna@web1:~$ top -o %CPU
anna@web1:~$ sudo ss -tunap | grep ESTAB
anna@web1:~$ sudo last -n 20
anna@web1:~$ awk -F: '$3 == 0 {print $1}' /etc/passwd
anna@web1:~$ sudo find /etc/systemd/system /etc/cron* -newer /etc/hostname -type f
anna@web1:~$ for u in /root /home/*; do sudo cat $u/.ssh/authorized_keys 2>/dev/null; done

last показва кой и кога е влизал, редът с awk показва всички акаунти с UID 0 (това трябва да е само root), а редът с find търси units и cron файлове, които са по-нови от файл, създаден при инсталацията.

Внимание: на сървър, който наистина е хакнат, и тези команди може да са подменени. Те Ви помагат да заподозрете нещо, но не доказват, че всичко е чисто.

Първите стъпки: спокойствие, изолиране, документиране

Най-важното в първите минути е да не изтривате неща в паника. Работете в следния ред.

1. Започнете дневник. Записвайте на хартия или на лаптопа си (не на сървъра) какво виждате, кога и какво правите. Това ще Ви трябва по-късно, за да откриете причината, за уведомление, за подаване на сигнал или за застрахователя Ви. Нидерландският NCSC също препоръчва това.

2. Изолирайте сървъра. Не му позволявайте да нанася още щети (спам, атаки, изпращане на данни навън), без да го изключвате:

• в защитната стена на доставчика (ако има такава) затворете всичко освен SSH от Вашия собствен адрес; или
• направете същото на самия сървър, през конзолата;
• ако няма друг начин: изключете сървъра през панела. Тогава обаче губите съдържанието на паметта.

3. Направете snapshot. Snapshot в панела запазва състоянието такова, каквото е в момента. Това е Вашето доказателство и Вашият източник, за да разберете по-късно как е влязъл нападателят, дори ако след това преинсталирате сървъра.

4. Защитете резервните си копия. Проверете дали резервните копия извън сървъра са все още непокътнати и се погрижете хакнатият сървър вече да няма достъп до тях (например като отнемете ключа за достъп на сървъра до хранилището за резервни копия). Нападателите се опитват да изтрият или да криптират и резервните копия.

Почистване или преинсталиране?

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

Затова съветът на администраторите, а и на нидерландския NCSC, е: преинсталирайте засегнатите системи и възстановете данните си от резервно копие, което самото не е заразено. Конкретно:

1. Нова инсталация (преинсталиране в панела или нов сървър).
2. Веднага основите от този курс: актуализации, обикновен потребител със sudo, SSH с нови ключове, защитна стена (модули от 2 до 5).
3. Инсталирайте отново приложенията си от официални източници, за предпочитане с Вашите compose файлове или бележки (урок 10.4).
4. Възстановете данните (база данни, качени файлове) от резервно копие отпреди инцидента. Не възстановявайте сляпо код или конфигурация: те може да съдържат задната врата. Преглеждайте критично и възстановените данни; нападателят може да е бил вътре по-дълго, отколкото предполагате.
5. Затворете пролуката, през която е влязъл нападателят. Иначе това ще се случи отново. Snapshot-ът от стъпка 3 помага при разследването.

Сменете всичко, което може да е изтекло

Приемете, че всичко, което е било на сървъра, е в ръцете на нападателя:

• SSH ключове: премахнете навсякъде публичните ключове, които са били на сървъра, и създайте нови двойки ключове, ако на сървъра е имало частни ключове.
• Пароли на бази данни, административни панели и потребители на приложението Ви.
• API ключове и токени (поща, плащания, облачно хранилище, хранилище за резервни копия) от .env файлове и конфигурацията: отнемете ги при съответната услуга и ги заменете.
• Сертификати: частният ключ на сертификата Ви е бил на сървъра. Поискайте отнемане на сертификата и заявете нов (с Let's Encrypt това става бързо, урок 7.3).

Уведомяване: GDPR (ОРЗД) и други

Ако на сървъра е имало лични данни (данни на клиенти, акаунти, имейл адреси), възможно е да има нарушение на сигурността на данните. GDPR (ОРЗД) (член 33) предвижда, че администраторът на лични данни уведомява надзорния орган за нарушението без ненужно забавяне и когато е възможно, не по-късно от 72 часа, след като е разбрал за него. В България това е Комисията за защита на личните данни (КЗЛД). Няколко важни момента:

• не е нужно да уведомявате, ако нарушението вероятно не създава риск за засегнатите лица; ако се колебаете, уведомете;
• ако все още нямате цялата информация, уведомете въпреки това в рамките на 72 часа и допълнете по-късно;
• хората, чиито данни са изтекли, информирате, ако за тях има висок риск;
• всяко нарушение записвате в собствен регистър, дори когато не е нужно да уведомявате.

Ако управлявате сървъра за клиент, обикновено сте обработващ лични данни: тогава трябва да информирате клиента (администратора на лични данни) без ненужно забавяне, за да може той да уведоми. Този урок не е правен съвет; при съмнение се обърнете към КЗЛД.

Освен това: съобщете на доставчика си за злоупотребата, извършена от сървъра Ви (той често вече я е забелязал), а при сериозна атака подайте сигнал до МВР (https://www.mvr.bg/) или ГДБОП (https://www.cybercrime.bg/). Ако организацията Ви попада в обхвата на Закона за киберсигурност (изменен през 2026 г., транспониране на NIS2), важат отделни, по-кратки срокове за уведомяване.

Подготовка: аварийният план

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

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

На практика

В екрана за VPS на WebOké ще намерите конзолата, snapshots, резервните копия и бутона за преинсталиране; при други доставчици те се наричат по подобен начин (console или VNC, snapshot, rescue, reinstall). Този курс е за самопомощ: никой не следи сървъра Ви и никой няма да разчисти инцидент вместо Вас. Точно затова е толкова важен авариен план, който можете да изпълните сами.

Обобщение

• Признаци: необяснимо натоварване, непознати процеси, услуги или ключове, странен изходящ трафик, променени или изчезнали файлове и логове.
• Първи стъпки: водете дневник, изолирайте сървъра, направете snapshot като доказателство, защитете резервните копия.
• Сървър, на който някой е имал root, не се почиства, а се преинсталира; данните се възстановяват от чисто резервно копие и пролуката се затваря.
• Сменете всички ключове, пароли, токени и сертификати, които са били на сървъра.
• Засегнати са лични данни? Уведомявате КЗЛД за нарушението по възможност в рамките на 72 часа и записвате всяко нарушение.

Тест (quiz)

Задача

Задача O10.3: Вашият авариен план на една страница. Напишете за собствения си сървър авариен план от най-много една страница A4: как влизате в панела, конзолата и snapshots; къде са резервните Ви копия и как ги възстановявате; какви тайни има на сървъра; кого трябва да информирате (и трябва ли да уведомите при нарушение на сигурността на данните); и какви са първите пет стъпки, които предприемате при подозрение за пробив. Пазете плана извън сървъра.

Още за четене

• Нямате повече достъп до Вашия VPS: какво да направите?
• Snapshots и backups на Вашия VPS
• Свързване на собствено ISO или преинсталиране на VPS
• Нидерландският NCSC, Gehackt, wat nu? (нидерландски източник): https://www.ncsc.nl/incidenten-en-herstellen/gehackt-wat-nu
• Нидерландският надзорен орган Autoriteit Persoonsgegevens, задължение за уведомяване при нарушения на сигурността на данните (нидерландски източник): https://www.autoriteitpersoonsgegevens.nl/nl/onderwerpen/beveiliging/meldplicht-datalekken
• VPS: от първото влизане до сигурен сървър 9.1: Блокиран достъп: не можете да влезете в сървъра си
• VPS: от първото влизане до сигурен сървър 9.5: Хакнат сървър? Първите стъпки