TrueNAS – storage security best practices

 

 

Dzisiaj chciałem poruszyć sprawę bezpieczeństwa samego serwera sieciowego TrueNAS. Na co zwrócić uwagę przy konfiguracji, jak prostymi tipami unikać zagrożeń no i kilka ważnych rzeczy które warto wiedzieć zanim weźmiemy się za nasz pierwszy TrueNAS. Co prawda opowiem na przykładzie właśnie TrueNAS ale to podejście i zalecenia są w większości uniwersalne i powinny tyczyć się wszystkich rodzajów pamięci masowych i dysków sieciowych.
Czyli TrueNAS security best practices.

  • 00:00 intro
  • 01:13 wprowadzenie
  • 02:25 WEB strona administracyjna
  • 04:28 ustawienie 2FA dla root
  • 05:31 dostęp przez SSH
  • 13:56 Pool raidz i dysk spare
  • 17:05 monitoring pro aktywny
  • 18:05 podsumowanie
  • 18:25 outro

No jak już mamy naszego TrueNAS, świeżo zainstalowanego, to czy jest jak powinno być? Na tyle ile dało się to zrobić domyślnie tak, ale powinniśmy jeszcze kilka rzeczy poprawić. Staram zebrać i opisać zbiór generalne wskazówki na potrzeby ogólnych zastosowań TrueNAS. Pokarzę jak część z nich skonfigurować na bazie TrueNAS-CORE-13.0-U3 aktualny na listopad 2022 jak nagrywam ten materiał.

 

Nadmienię, że jest często poszczególne z tych rozwiązań czasem będą przesadą ze względu na albo niewielka instalacja albo nikłe ryzyko. Ale za każdym razem właściciel danych powinien podejmować decyzje z jakim ryzykiem jest w stanie się pogodzić. Dodatkowo pamiętajmy, że wymieniona lista rzeczy nigdy nie będzie całkowicie kompletna na tyle żeby móc powiedzieć, że jesteśmy całkowicie bezpieczni. Regularnie odkrywane są nowe podatności czy nowe metody ataków.

WEB strona administracyjna

Zacznijmy od strony administracyjnej WEB. Taką podstawową zasadzą od której chyba powinniśmy zacząć jest, żeby nigdy nie wystawiać strony administracyjnej do Internetu. Tak jak można sobie czasem wyobrazić, że jakaś usługa jest widoczna bezpośrednio z Internetu, choć unikał bym jak tylko to możliwe, tak nie potrafię sobie wyobrazić sytuacji gdzie otwieramy dostęp z Internetu do panelu administracyjnego. Najlepiej jeżeli panel administracyjny dostępny będzie w osobnej sieci dostępnej tylko dla właściwych użytkowników za firewallem czy przez VPN. Warto trzymać się zasady, żeby nie tylko panel administracyjny ale i każda usługa miała przydzielony oddzielny IP. Ułatwia to potem blokowanie i otwierać dostęp do poszczególnych usług.

 

Następnie warto zadbać żeby nasz panel administracyjny używał szyfrowanego tylko dostępu czyli HTTPS zamiast HTTP.

 

Odnośnie samego użytkownika administracyjnego root zdecydowanie warto żeby miał odpowiednio długie i złożone hasło i oczywiście skonfigurowane 2FA

 

Jeżeli planujemy używać dostępu do naszego serwera plików przez konsolę SSH to używajmy klucza zamiast haseł.

 

Dobrym zwyczajem jest pozostawianie włączonych wyłącznie wykorzystywanych usług. Jeżeli mamy mniej mniej włączonych usług jesteśmy narażeni z mniej potencjalnych problemów które mogą wyniknąć w przyszłości.

 

SMB

Podstawową formą ochrony samych danych przed nieumyślną zmianą, przypadkowym skasowaniem lub przez atakiem szyfrującym dane ransomware jest konfiguracja snapshot. Pozwalają one przechowywać zarówno historyczne wersje plików jak i pliki skasowane.

Tutaj możesz dowiedzieć się więcej.

 

Warto dobrze zaplanować datasety. Można wszystkie nasze dane udostępniać w jednym udziale sieciowym i pewnie się to sprawdzi przy małej instalacji. Warto jednak rozważyć stworzenie osobnych udziałów sieciowych dla różnych działów firmy, grup ludzi, przeznaczenia. Można wtedy zależnie od udziału przyznawać prawa dostępu właściwym osobom, blokować dostęp z określonej części sieci. Dodatkowo jeżeli przydarzy się atak szyfrujący pliki to zaszyfruje tylko część danych a nie wszystkie. Wtedy przywracanie shapshptu na przykład z wczoraj sprawi, że stracimy dzień zmian tylko części naszych danych.

Serwer dyski i inne

Przy tworzeniu Poola z danymi warto rozważyć szyfrowanie danych na dyskach. Sprawia to, że dane zapisane na dyskach są bezwartościowe  jeżeli nie zna się hasła szyfrującego. Dalej tworząc nasz nowy Pool koniecznie należy użyć minimum RAID-Z1 dająca odporność na awarię jednego dysku. Zalecam rozważenie RADI-Z2 dającą odporność na awarię dwóch dysków. Dodatkowo warto rozważyć użycie dysku zapasowego SPARE. Działa to w ten sposób, że w wypadku awarii któregoś z dysków należącego do poola dysk SPARE automatycznie przejmuje role uszkodzonego dysku i RAID jest od razu odbudowywany.

 

Następnym zagrożeniem dla naszych danych jest utrata zasilania. Co prawda ZFS dzięki między innymi tzw Copy on Write wydaje się być mocno odporny na uszkodzenia danych podczas awarii zasilania ale część danych może dostać po prostu nie zapisana. Żeby się ustrzec przed takimi niespodziankami ważne jest, żeby skonfigurować serwer i podłączony UPS, żeby wyłączyły się przy braku zasilania.

 

Jak już jesteśmy przy fizyczności naszego serwera to warto zastanowić się kto i kiedy ma do niego fizyczny dostęp. Najlepiej oczywiście w dedykowanym zamkniętym pomieszczeniu z klimatyzacją. Choć nie zawsze jest taka możliwość to jednak warto się zastanowić czy ktoś nie odłączy mu przez przypadek zasilania albo nie zaleje kawą. Choć tu, żeby na poważnie zaszkodzić serwerowi pewnie była by potrzeba bardziej jakaś mała kawowa powódź.

 

Jeżeli już mamy nasz serwer skonfigurowany i bezpieczny to jeszcze, pamiętając, że RAID to nie backup, musimy zadbać o to, żeby nasze dane miały swój backup. Czyli replikacja danych na inny fizyczny serwer najlepiej w innej lokalizacji za względu na kradzieże pożary i inne zdarzenia losowe. [link to materiału o replikacji]

 

Teraz wracając na chwilę do oprogramowania warto aktualizować naszego TrueNAS no i nie zapomnieć o backup samej konfiguracji TrueNAS to czasem umyka ale warto się upewnić, że robimy backup konfiguracji no i… trzymamy go nie tylko na naszym NAS.

 

Monitoring pro aktywny

Jak zakończymy konfiguracje serwera i wszystko jest przemyślane, skonfigurowane, zabezpieczone to przychodzi moment na codzienną rzeczywistość. Nikt nie tworzy systemów IT żeby mieć więcej pracy i potem regularnie się do nich ręcznie logować, testować, sprawdzać.

Elementarnym minimum jest konfiguracja e-mail na naszym dysku sieciowym, żeby mógł sam nas powiadomić, że popsuł się dysk, że brakuje miejsca itp.

Dobrym zwyczajem jest monitorowanie aktywne urządzenia. Pamiętajmy, że taki mail może nie wyjść lub nie dojść z wielu powodów. Zwłaszcza, że na ogół taki serwer działa spokojnie kilka lat bez żadnej usterki. A kto będzie regularnie sprawdzał czy taki skonfigurowany kilka lat temu mail działa, wysyła? Dlatego warto rozważyć jakiś aktywny monitoring sprawdzający czy nasze urządzenie działa, czy wszystkie dyski są sprawne, czy nie są bliskie przepełnienia. Bo po co nam zapasowe dyski czy zasilacze jak nie zostaniemy poinformowani, że już nie mamy zapasu bo właśnie się coś zepsuło i co prawda jeszcze działa ale już nie mamy żadnego zapasu i czas najwyższy ruszyć tyłek wymienić dysk czy zasilacz.

 

ZAPRASZAM DO OGLĄDANIA