Сигурност на домашни и DIY сървъри: Практическо ръководство за защита на Linux машини
Никой не те атакува лично. Просто скенерът е стигнал до твоя IP адрес.
Първото нещо, което видях в лога на първия си публичен сървър, беше опит за вход с потребител admin. Машината беше онлайн от четиринадесет минути. Не защото сървърът ми беше известен, ценен или специално набелязан, а защото автоматизирани скенери обхождат публичното интернет пространство денонощно и търсят една и съща комбинация - отворен порт, стара услуга и слаба парола.
Това е реалността при сигурността на домашните и DIY сървърите. В повечето случаи не се защитаваш от гениален хакер, който е изучавал инфраструктурата ти седмици наред. Защитаваш се от автоматизиран шум, който намира забравената врата, преди ти да си спомниш, че си я оставил отворена.
Защо домашният сървър е реална цел
Домашният NAS, лабораторният Proxmox хост, Raspberry Pi, самостоятелният уеб сървър и машината с Docker контейнери са част от същия интернет, в който живеят банките, облачните платформи и корпоративните мрежи. Разликата е, че големите организации обикновено имат екипи, процедури и системи за наблюдение, докато домашният администратор има работа, семейство и навика да казва: „Ще го оправя през уикенда.“ Интернет обаче не чака уикенда.
Целта на добрата защита не е да направиш машината магически непробиваема. Такава машина няма. Целта е да намалиш повърхността за атака, да ограничиш щетите при грешка и да разбереш бързо, когато нещо се държи различно от очакваното.
Слой 0: Разбери какво се вижда отвън
Не можеш да защитиш услуга, за която не знаеш, че е публична. Преди firewall, fail2ban и сложни табла за наблюдение трябва да имаш точна картина на собствената си инфраструктура - кои машини съществуват, какви услуги работят и кои портове са достъпни от интернет.
- Провери локално слушащите портове с ss -tulpn, lsof -i или еквивалентен инструмент за твоята система.
- Сканирай публичния си IP адрес от външна мрежа. Проверка от същия LAN може да даде подвеждащи резултати заради NAT loopback и настройките на рутера.
- Провери отделно IPv4 и IPv6. При IPv6 не трябва да разчиташ на NAT като защитна бариера - firewall правилата трябва да бъдат приложени и проверени изрично.
- Прегледай всички port forwarding, DMZ и UPnP правила в рутера. Временните изключения имат лошия навик да стават постоянни.
- Поддържай кратък регистър: машина, услуга, порт, причина да бъде достъпна и кой я поддържа. Ако не можеш да обясниш защо даден порт е отворен - затвори го.
Слой 1: Сигурен SSH достъп и управление на потребителите
SSH обикновено е основният административен вход към Linux сървъра. Точно затова трябва да бъде конфигуриран така, че една открадната или отгатната парола да не е достатъчна за достъп до машината. Тук се печели или губи огромна част от битката.
- Използвай SSH ключове и изключи входа с парола чрез PasswordAuthentication no. Това премахва brute force атаките срещу потребителски пароли.
- Забрани директния root вход чрез PermitRootLogin no. Влизай с отделен потребител и използвай sudo само когато е необходимо.
- Защити частния SSH ключ с добра passphrase. Ключ без passphrase върху откраднат лаптоп е удобство за човека, който го е откраднал.
- Ограничи разрешените потребители чрез AllowUsers или AllowGroups, когато това е практично.
- Използвай отделни ключове за различните устройства и администратори. Един общ ключ навсякъде превръща компрометирането на една машина в проблем за цялата инфраструктура.
- Нестандартният SSH порт не е истинска защитна стена. Той просто премахва голяма част от елементарния автоматизиран шум и прави логовете по-четими.
- Добави fail2ban или CrowdSec като допълнителен слой. fail2ban реагира на локалните логове, а CrowdSec може да използва и споделена репутационна информация за известни злонамерени адреси.
Задължителна предпазна мярка при промяна на SSH конфигурацията. Никога не рестартирай sshd и не затваряй текущата си сесия, преди да си проверил, че новият достъп работи. Остави активната връзка отворена, отвори втори терминал и влез с ключа. Едва след успешен вход затвори първата сесия. Ако сървърът е VPS или отдалечена машина без конзолен достъп, тази проверка е разликата между дребна конфигурационна грешка и пълна преинсталация.
Уточнение за fail2ban, което често се пропуска. След като входът с парола вече е изключен, fail2ban не пази SSH от нищо съществено, защото няма какво да бъде отгатвано. Реалната му стойност се измества към уеб панелите, форума, пощенския сървър и API-тата, където автентикацията все още е с пароли. Не приемай, че си защитен там, където всъщност вече си затворил вратата по друг начин.
Не забравяй и старите акаунти. Потребител, който вече не се използва, няма причина да остава активен. Преглеждай периодично членовете на групите с административни права, разрешените SSH ключове и съдържанието на authorized_keys.
Слой 2: Firewall, VPN и сегментация на мрежата
Добрата мрежова защита започва с проста философия: всичко е затворено, докато не докажеш защо трябва да бъде отворено. Дали ще използваш nftables, ufw, firewalld или правилата на отделен рутер е второстепенно. Важна е логиката - минимален достъп и ясна причина за всяко изключение.
- Използвай политика default deny за входящия трафик и разрешавай само конкретните необходими портове.
- Провери правилата както за IPv4, така и за IPv6. Firewall, който пази само единия протокол, пази само половината врата.
- Използвай WireGuard за административни панели, NAS интерфейси, Proxmox, Home Assistant и други услуги, предназначени само за теб. Ако една услуга няма причина да бъде публична, тя трябва да остане зад VPN.
- Изключи UPnP на рутера, освен ако нямаш конкретна и контролирана причина да го използваш. Иначе различни устройства могат сами да отварят входящи портове.
- Не поставяй вътрешен сървър в DMZ само защото настройването на отделни правила е досадно. DMZ бутонът често е административният еквивалент на това да махнеш входната врата, защото ключалката заяжда.
- Изолирай IoT устройствата в отделен VLAN или гост мрежа. Евтината камера, телевизорът и умната крушка нямат причина да виждат NAS-а, хипервайзора или работните ти компютри.
Сегментацията не предотвратява всяка атака, но ограничава движението след пробив. Ако едно устройство бъде компрометирано, нападателят не трябва автоматично да получава директен път към всичко останало.
Слой 3: Защита на публичните услуги и Docker контейнерите
Всеки публичен уеб панел, форум, облачна услуга или самостоятелно приложение добавя нов код и нови зависимости към повърхността за атака. Затова публичните услуги трябва да бъдат малко, ясно документирани и редовно обновявани. „Временно тестово приложение“ е едно от най-дълго живеещите същества в домашния център за данни.
- Постави публичните HTTP и HTTPS услуги зад reverse proxy. Така получаваш една контролна точка за TLS сертификати, логове, ограничения на заявките и правила за достъп.
- Използвай валидни TLS сертификати с автоматично подновяване и наблюдение на срока им. Изтекъл сертификат в три през нощта е класика, но не е задължителен ритуал.
- Активирай двуфакторна автентикация навсякъде, където приложението я поддържа. За предпочитане използвай TOTP или хардуерен ключ, а не само SMS.
- Ограничавай административните панели по IP адрес, VPN или допълнителна автентикация, когато това е възможно.
- Конфигурирай вътрешните приложения да слушат само на 127.0.0.1, частен адрес или Docker мрежа, когато достъпът до тях трябва да минава единствено през reverse proxy.
- Не стартирай контейнерите като root, когато приложението позволява друг потребител. Не използвай --privileged по навик и не монтирай Docker socket в контейнер без много сериозна причина.
- Не записвай пароли, API ключове и токени директно в публични compose файлове или Git хранилища. Използвай environment файлове с правилни права, secret механизми или отделна система за управление на тайни.
- Ако не помниш защо си инсталирал дадена услуга, спри я. След това провери дали някой действително ще забележи липсата ѝ.
Слой 4: Актуализации и контрол на зависимостите
Необновената система не става по-стабилна с времето. Тя просто натрупва известни уязвимости, за които вече има готови скенери и публични exploit инструменти. Това важи не само за операционната система, а и за уеб приложенията, плъгините, контейнерните образи, reverse proxy сървъра и фърмуера на рутера.
- На Debian и Ubuntu използвай unattended-upgrades за автоматично инсталиране на security актуализации.
- Следи кои актуализации изискват рестарт на услуга, контейнер или kernel. Автоматичната инсталация не означава автоматично активирана защита.
- Използвай официални или доверени хранилища. Случаен install script от интернет е удобен начин да дадеш root права на човек, чието име дори не знаеш.
- Обновявай Docker образите контролирано. Новият tag не гарантира нито сигурност, нито съвместимост, затова тествай важните услуги преди продукционното обновяване.
- Премахвай ненужните пакети, стари kernel версии, неизползвани контейнери и забравени repository ключове.
Автоматичните security актуализации са добър слой, но не са заместител на наблюдението. Те са роботът, който сменя счупената ключалка. Ти все още трябва да провериш дали вратата се затваря.
Слой 5: Бекъп по правилото 3-2-1-1-0
Класическото правило 3-2-1 означава три копия на данните, върху два различни типа носители, като едно копие се съхранява извън основното местоположение. Модерният вариант на правилото, наложил се в бекъп индустрията след вълната от ransomware атаки, добавя още две условия - едно копие да бъде офлайн или неизменяемо и възстановяването да завършва с нула непроверени грешки.
- Поддържай поне три копия на важните данни.
- Използвай поне два различни носителя или различни системи за съхранение.
- Съхранявай поне едно копие извън основната машина или физическото местоположение.
- Поддържай поне едно офлайн или immutable копие, което продукционният сървър не може да изтрие или презапише.
- Използвай отделни идентификационни данни за резервното хранилище. Ако компрометираният сървър притежава пълните административни права върху бекъпа, нападателят вероятно ще ги притежава също.
- Тествай възстановяването периодично. Не само дали архивът се отваря, а дали можеш да възстановиш работеща услуга, база данни, права, конфигурация и зависимости.
Ransomware не се интересува кое устройство наричаш „бекъп“. Ако резервното копие е постоянно монтирано и достъпно с права за изтриване, то е просто още една папка, която може да бъде криптирана.
Слой 6: Логове, мониторинг и ранно откриване
Пробивът рядко започва с червен екран и надпис „Хакнаха те“. По-често се появява като нов процес, необичаен вход, странен DNS трафик, внезапно натоварване или порт, който вчера не е слушал. Затова някой трябва да наблюдава машините, когато ти не ги гледаш.
- Изпращай важните логове към отделна машина или централизирана система. Логовете върху компрометирания сървър могат да бъдат изтрити или променени.
- Използвай Uptime Kuma за достъпност и срокове на сертификати. За повече дълбочина използвай Netdata, Prometheus, Grafana или друга система, която разбираш и действително ще следиш.
- Настрой известия за неуспешни входове, нови административни потребители, промени в SSH ключовете и необичайна sudo активност.
- Следи за нови процеси и услуги, които започват да слушат на мрежов порт.
- Наблюдавай дисковото пространство, SMART състоянието, RAID масивите, температурата, натоварването и грешките във файловата система. Сигурността не помага много, ако дискът тихо умира от шест месеца.
- Следи срока на домейните и TLS сертификатите. Известие седмица предварително е по-евтино от аварийна диагностика през нощта.
- Honeypot може да покаже какво реално опитват автоматизираните нападатели, но трябва да бъде изолиран от продукционната мрежа и да няма доверен достъп до останалите системи.
Слой 7: План при съмнение за пробив
Добрата сигурност не е само превенция. Трябва да знаеш какво ще направиш, когато забележиш неизвестен процес, подозрителен вход или променен системен файл. Паниката е лош incident response план, макар да е най-често използваният.
- Изолирай засегнатата машина от мрежата, без веднага да унищожаваш потенциалните доказателства.
- Не рестартирай машината. Първият инстинкт на всеки е да я рестартира, но точно това изтрива съдържанието на паметта, активните мрежови връзки и работещите процеси - често единствената следа от това какво реално се е случило. Рестартът не премахва нападателя, ако достъпът му е бил направен постоянен. Той премахва само доказателствата.
- Запази логове, списък на процесите, активните връзки и важната системна информация, ако можеш да го направиш безопасно.
- Смени паролите, SSH ключовете, API токените и другите идентификационни данни от доверена машина.
- При сериозно съмнение не се опитвай просто да „почистиш“ системата и да продължиш. Най-надеждният подход е преинсталиране от доверен източник и възстановяване от проверен бекъп.
- Провери останалите машини за същите акаунти, ключове, уязвими версии и следи от странично движение.
- Документирай причината за пробива и промени системата така, че същата грешка да не може да се повтори по същия начин.
Минимален checklist за защита на домашен Linux сървър
- Знам кои услуги и портове са публично достъпни.
- Проверил съм отделно IPv4 и IPv6.
- SSH работи само с ключове и директният root вход е забранен.
- Тествал съм новия SSH достъп от втора сесия, преди да затворя първата.
- Firewall политиката е default deny.
- Личните административни услуги са зад WireGuard или друга VPN връзка.
- UPnP е изключен и няма забравени port forwarding правила.
- IoT устройствата са отделени от сървърите и работните станции.
- Публичните уеб услуги са зад reverse proxy и използват валиден TLS сертификат.
- Security актуализациите се инсталират редовно.
- Имам офлайн или immutable бекъп с отделни идентификационни данни.
- Тествал съм реално възстановяване от резервно копие.
- Получавам известия при проблем, вместо да го откривам случайно след седмица.
- Знам какво ще направя първо, ако утре открия непознат процес на машината.
Въпросът към вас
Как защитавате собствените си домашни сървъри, лаборатории, NAS системи, Docker хостове и IoT устройства? Интересуват ме не идеалните конфигурации от документацията, а решенията, които реално работят при вас - включително компромисите, които сте направили.
- Излагате ли услуги директно в интернет, или административният достъп е изцяло зад VPN?
- Използвате ли fail2ban, CrowdSec, собствена система или разчитате само на SSH ключове и firewall?
- Сегментирали ли сте IoT устройствата и домашната мрежа във VLAN-и?
- Имате ли отделна защита и правила за IPv6?
- Кога за последно възстановихте реално работеща услуга от бекъп?
- Кой урок за сървърната сигурност научихте по трудния начин?
Тук няма срамни отговори. Всеки, който е държал собствен сървър онлайн достатъчно дълго, има поне една история, започваща с: „Мислех, че този порт е затворен.“ Полезната част започва след това - когато разкажем какво сме променили, за да не повторим същата грешка.
Ключови теми: сигурност на домашен сървър, защита на Linux сървър, SSH hardening, firewall, WireGuard VPN, fail2ban, CrowdSec, Docker security, IPv6 firewall, NAS сигурност, мониторинг и 3-2-1-1-0 бекъп.
Полезна документация: OpenSSH sshd_config, nftables, WireGuard, CrowdSec, Debian unattended-upgrades, Docker security, Uptime Kuma, Prometheus и Grafana.
toni@dtgarage:~$ whoami
Тони Ангелчовски | Ексклузивно за DTGaraGe
toni@dtgarage:~$ cat LICENSE
Копирането и препубликуването без разрешение не е позволено.
toni@dtgarage:~$ ./support.sh
Подкрепи DTGaraGe и независимото техническо съдържание
toni@dtgarage:~$ █
Тони Ангелчовски | Ексклузивно за DTGaraGe
toni@dtgarage:~$ cat LICENSE
Копирането и препубликуването без разрешение не е позволено.toni@dtgarage:~$ ./support.sh
Подкрепи DTGaraGe и независимото техническо съдържаниеtoni@dtgarage:~$ █
