Stavíme vlastní NAS: bezpečnost, ochrana a firewall

Pokud chcete mít NAS aktuální a neřešit bezpečnostní aktualizace, můžete nechat Ubuntu Server, aby se aktualizoval sám pomocí Unattended Upgrades.

V první řadě musíte mít nainstalovaný balík unattended-upgrades:

apt install -y unattended-upgrades

Ve výchozím nastavení se upgrade pouští každý den v 6:00 plus mínus hodina, můžete si to ověřit výpisem časovače:

systemctl cat apt-daily-upgrade.timer
# /usr/lib/systemd/system/apt-daily-upgrade.timer
[Unit]
Description=Daily apt upgrade and clean activities
After=apt-daily.timer

[Timer]
OnCalendar=*-*-* 6:00
RandomizedDelaySec=60m
Persistent=true

[Install]
WantedBy=timers.target

Pokud byste chtěli, aby se pouštěl upgrade přesně ve 4:00, tak to můžete docílit následovně:

systemctl edit apt-daily-upgrade.timer
# Doplnit
[Timer]
OnCalendar=*-*-* 4:00
Persistent=true
RandomizedDelaySec=0

Pomocí nastavení OnCalendar můžete docílit i jiného časování. Například každé pondělí, prvního v měsíci, první patek v měsíci a podobně.

Určitě nepřehlédněte soubor /etc/apt/apt.conf.d/50unattended-upgrades, kde můžete ovlivňovat co se upgradovat bude a co ne. Jak podle zdroje (origin) balíčku, tak podle názvu. Můžete povolit automatický reboot systému a další.

Souborová služba

Záleží na tom, co jste nakonec použili: Sambu, NFS, WebDav, FTP nebo jinou. Myslete na to, jestli k ní přistupujete přímo z internetu, pokud ano, použijte implementace s TLS.

Za zmínku stojí i režim guest/anonymní. Některé služby to podporují, ověřte si, že nedochází k přístupu bez autorizace.

SSH server

Hlavní přístupový bod, který používáme pro správu NAS. Už v základu má Ubuntu Server nastavených několik věcí, takže se podíváme na  /etc/ssh/sshd_config:

• PermitRootLogin prohibit-password  — pro uživatele root musíte použít jiný způsob přihlášení než heslo, ideálně SSH klíče. Doporučuji to přepnout na no a používat sudo, pokud nemáte dobrý důvod přihlašovat se jako root.
• AllowUsers vasuzivatel  — doporučuji zapnout. Pokud používáte Sambu nebo něco jiného a vytváříte uživatele v systému, je dobré mít pod kontrolou, kdo může přistupovat přes SSH. Do AllowUsers dejte uživatele, kterého používáte pro správu. Kromě uživatele můžete omezit i síť, ze které se může přihlásit.
• PasswordAuthentication no  — pokud bude NAS dostupný z internetu, doporučuji zakázat přihlášení heslem komplet.
• ClientAliveInterval 300, ClientAliveCountMax 0  — zajistí, že neaktivní spojení se automaticky ukončí po uplynutí intervalu.

UFW

Uncomplicated Firewall — jednoduchý nástroj pro správu firewallu. Na zprovoznění není nic složitého: stačí ho aktivovat a povolit základní služby, které chcete mít přístupné. Co se týče nevýhod, není podle mě vhodný na složitější úlohy.

# Instalace
apt install ufw

# Povolíme své aplikace
ufw allow "Nginx Full"
ufw allow OpenSSH
ufw allow Samba

# Zapneme firewall
ufw enable

# Zobrazení stavu
ufw status

# Hint: Zobrazení dostupných predefinovaných aplikací
ufw app list

Pokud máte komplexnější nároky, je pro vás určitě lepší cesta použít bud nativní nftables, nebo řešení typu FirewallD nebo Shorewall.

Fail2Ban

Tato služba je skvělá, pokud máte NAS dostupný z internetu. Funguje na jednoduchém principu – sleduje logy a pokud zjistí, že dochází k častým neúspěšným přihlášením, automaticky zablokuje IP adresu klienta. Velmi užitečné hlavně pro službu SSH, ale dá se takto chránit i spousta dalších aplikací. Můžete si také nadefinovat vlastní pravidla, pokud je nenajdete v oficiálním repozitáři.

Nemusí se jednat jen o neúspěšné přihlášení, ale i jinou aktivitu, kterou chcete zamezit.

# Instalace
apt install fail2ban

Konfiguraci najdete standardně v /etc/fail2ban. Doporučuji si v klidu projít dokumentaci a podívat se, jaké máte možnosti. Níže popisuji základní strukturu:

• action.d  – definice dostupných akcí. „Action“ určuje, co se má stát při detekci problému. Můžete si vytvořit vlastní, ale většina běžných případů už tam je připravená. UFW je mezi nimi.
• fail2ban.conf  – hlavní konfigurační soubor. Není nutné ho měnit.
• fail2ban.d  – pokud budete potřebovat něco přenastavit, vytvořte si vlastní soubor v tomto adresáři a přepište tím výchozí hodnoty.
• jail.d  – sem přidáváme konkrétní nastavení toho, co chceme sledovat.

Vytvoříme soubor /etc/fail2ban/jail.d/nas.conf s následujícím obsahem:

[DEFAULT]
banaction = ufw
application = OpenSSH
backend = systemd

[sshd]
enabled = true

Využíváme připravených pravidel a akcí, takže si nemusíte nic psát sami.

• banaction  – jakou akci použít. V našem případě UFW.
• application  – tohle je info pro UFW, aby věděl, že jde o OpenSSH, a mohl podle toho blokovat klienty.
• backend  – určuje, co se použije k detekci změn v logu. V našem případě  systemd.

Neberte to ale jako dogma — určitě si vše otestujte, ať víte, že vám to opravdu funguje. Já jsem si z jiného stroje schválně zadal špatné heslo a na NASu to pak vypadalo takhle:

tail -f /var/log/fail2ban.log
> 2025-07-16 14:18:36,205 fail2ban.filter         [2232402]: INFO    [sshd] Found 147.32.xx.xx - 2025-07-16 14:18:35
> 2025-07-16 14:18:39,455 fail2ban.filter         [2232402]: INFO    [sshd] Found 147.32.xx.xx - 2025-07-16 14:18:39
> 2025-07-16 14:18:44,955 fail2ban.filter         [2232402]: INFO    [sshd] Found 147.32.xx.xx - 2025-07-16 14:18:44
> 2025-07-16 14:18:56,705 fail2ban.filter         [2232402]: INFO    [sshd] Found 147.32.xx.xx - 2025-07-16 14:18:56
> 2025-07-16 14:19:06,955 fail2ban.filter         [2232402]: INFO    [sshd] Found 147.32.xx.xx - 2025-07-16 14:19:06
> 2025-07-16 14:19:06,969 fail2ban.actions        [2232402]: NOTICE  [sshd] Ban 147.32.xx.xx

ufw status
> Status: active
>
> To                         Action      From
> --                         ------      ----
> Anywhere                   REJECT      147.32.xx.xx               # by Fail2Ban after 5 attempts against sshd

fail2ban-client banned
> [{'sshd': ['147.32.xx.xx']}]

# pokud bychom chteli IP znova povolit
fail2ban-client unban 147.32.xx.xx

Fail2Ban – OwnCloud

Udělejme si i příklad toho, jak detekovat přihlášení do našeho ownCloud a zablokovat klienta.

Definujeme filtr pro to, co chceme v logu hledat, v souboru  /etc/fail2ban/filter.d/owncloud.conf:

[Definition]
failregex=.*Login failed: \'.*\' \(Remote IP: \'\'\).*
ignoreregex =

Doplníme jail v /etc/fail2ban/jail.d/nas.conf  přidaním:

[owncloud]
banaction = ufw[kill-mode="ss", blocktype="deny"]
enabled = true
filter = owncloud
maxretry = 5
logpath = /var/lib/containers-data/owncloud/server/files/owncloud.log
backend = auto

Ted už jen restartneme službu fail2ban:  systemctl restart fail2ban.service

Co jsme to vlastne nastavili ?

• banaction = ufw[kill-mode="ss", blocktype="deny"], použijeme ufw ale při zákazu také ukončíme všechna spojení s klientem a zablokujeme typem DENY, ve výchozím stavu se blokuje zprávou ICMP port unreachable. Dávám to sem hlavně jako příklad toho, co lze nastavit.
• enabled = true, aktivace jailu
• filter = owncloud, jaký chceme použít filtr, ten co jsme vytvořili
• maxretry = 5, kolik výskytů tolerujeme, než zabanujeme klienta
• logpath = ...., cesta k logu
• backend = auto, souborový backend, standardně by se použil systémový journal log

Zkušenosti s provozem

Jak to tedy dopadlo? Rád bych sesumíroval některé informace, na které jste se v komentářích často ptali. Jsem rád, že seriál vyvolal věcnou diskuzi a moc rád jsem viděl v komentářích vaše pohledy na tuto problematiku s konkrétními doporučeními nebo odkazy.

Z mého pohledu se stavba povedla, splnilo to moje požadavky a hodně věci jsem si u toho vyzkoušel. Co se týče kvality a výdrže základní desky, ukáže až čas. Zatím se žádné potíže neobjevily.

NAS je tichý, prakticky ho vůbec není slyšet. Samozřejmě to závisí hlavně na použitých discích a větrácích. NAS jsem prověřil i pomocí testů s utilitou fio a CPU Burn. Během testování i při celé migraci dat tam a zpět se choval stabilně — a to jak z hlediska výkonu, tak i teplot a spotřeby.

Provozní data

• Spotřeba během výkonnostních testů při největším diskovém a CPU zatížení – 85 W
• Spotřeba při běžné práci s NAS – 40 W
• Spotřeba v režimu standby disků (většina času) – 18 W, ze statistik je v mém případě vidět, že NAS pracuje s úložištěm jen cca 2,5 hodiny denně a tedy v standby režimu je 90 % času.
• Teplota disků během migrace a testování – 41 °C
• Teplota disků při standardní práci – 34 °C
• Přenos přes Samba v lokální síti – asi 124 MB/s, domácí síť je jen na gigabitu
• Přenos přes Samba + WireGuard z internetu – asi 90 MB/s, reálný přenos přes internet

Kolik co stálo?

• Základní deska – 3070 CZK
• 16 GB RAM – 900 CZK
• Mini PSU ATX – 300 CZK
• Tlacitka (power a reset) – 240 CZK
• SATA data a power kabely – 300 CZK
• Vetrak 12cm – 120 CZK
• Filament ASA části – 117 CZK
• Filament PLA části – 15 CZK
• Filament PETG části – 340 CZK

Celkové náklady na tento projekt byly tedy přibližně 5 402 CZK.

Kolik mi to zabralo času?

• Testování desky – 2 hodiny
• 3D Modeling – 9 hodin
• Instalace systému – 1 hodinu
• Konfigurace, migrace a zprovoznění služeb – 6 hodin
• Testování výkonu – 2 hodiny , počítám jen svůj čas, který jsem u toho seděl

Celková moje časová investice byla kolem 20 hodin.

Proč takový projekt vůbec dělat?

Naučí vás to hodně, hlavně pokud jste mladí a ještě máte hodně času a málo zkušeností. Získáte znalosti a schopnosti a odvahu hlavně pro menší, ale i větší věci. Během stavby a konfigurace narazíte na celou řadu praktických problémů, jejichž řešení vás naučí nejen trpělivosti, ale i samostatnosti a logickému myšlení.

Zároveň získáte schopnost rychle a efektivně řešit situace, ve kterých žádné hotové řešení neexistuje nebo nevyhovuje vašim představám a potřebám. Uvědomíte si, že velké množství věcí dokážete vyřešit sami, možná ne dokonale, ale dostatečně dobře.

Zdroje

• Všechny zdroje z článku jsou dostupné v repozitáři na GitHubu
• 3D model NASu najdete na Printables.com.