Współczesna infrastruktura teleinformatyczna opiera się na wydajnym i bezpiecznym współdzieleniu zasobów dyskowych. Protokół SMB (Server Message Block), którego historyczne korzenie sięgają prac firmy IBM z 1983 roku, został zaadaptowany i rozwinięty przez firmę Microsoft, stając się uniwersalnym standardem w heterogenicznych sieciach przedsiębiorstw. Dzięki projektowi Samba, zainicjowanemu przez Andrew Tridgella, systemy Unix i Linux mogą pełnić rolę serwerów plików dla stacji Windows, a także pełnoprawnych kontrolerów domeny Active Directory.

Z kolei Network File System (NFS), stworzony przez Sun Microsystems w 1984 roku, powstał jako integralna część architektury Open Network Computing (ONC). Protokół ten zaprojektowano z myślą o bezszwowej integracji ze strukturą wirtualnego systemu plików (VFS) jądra systemów uniksowych. Zdalny zasób dyskowy NFS jest montowany bezpośrednio w lokalnym drzewie katalogów, co sprawia, że dla procesów w przestrzeni użytkownika dostęp do plików zdalnych jest całkowicie przezroczysty i realizowany za pomocą standardowych wywołań systemowych POSIX (takich jak open, read, write, close).

Wybór pomiędzy protokołem SMB a NFS determinowany jest przede wszystkim strukturą środowiska systemowego organizacji oraz wymaganiami dotyczącymi kontroli dostępu. Podczas gdy SMB doskonale integruje się z architekturą Active Directory i oferuje rozbudowane listy kontroli dostępu Windows NT ACL, NFS (zwłaszcza w wersji NFSv4) stanowi optymalne rozwiązanie dla farm serwerów linuksowych, klastrów wirtualizacyjnych (np. VMware ESXi, Proxmox VE) oraz systemów wielkich zbiorów danych (Big Data), zapewniając bezpośrednią zgodność z semantyką uprawnień POSIX i minimalny narzut protokołu transportowego.

Wyjaśnienie skrótów i pojęć:
SMB (Server Message Block) – protokół warstwy aplikacji do współdzielenia plików, drukarek i potoków, rozwijany przez Microsoft i opisany w specyfikacji MS-SMB2.
CIFS (Common Internet File System) – historyczna nazwa dialektu SMBv1, obecnie odradzana z powodu braku bezpieczeństwa.
NFS (Network File System) – protokół współdzielenia plików w systemach Unix i Linux, standaryzowany przez IETF, wersja NFSv4 opisana w RFC 7530.
Samba – wolna implementacja protokołów SMB dla systemów Unix i Linux, umożliwiająca pracę serwera plików dla stacji Windows.
POSIX / Windows ACL – dwa modele uprawnień: uniksowe bity dostępu oraz rozbudowane listy kontroli dostępu systemu Windows.

Przydatne łącza: Samba (dokumentacja); NFSv4 - RFC 7530; Microsoft - protokół SMB.

Głównym celem niniejszego modułu dydaktycznego jest wykształcenie u inżynierów sieciowych i administratorów systemów kompleksowych kompetencji w zakresie projektowania, wdrażania i utrzymania wydajnych oraz bezpiecznych sieciowych magazynów danych. Współczesny administrator nie może ograniczać się wyłącznie do powierzchownej znajomości domyślnych plików konfiguracyjnych, lecz musi precyzyjnie rozumieć procesy zachodzące w warstwie sieciowej, transportowej i aplikacyjnej podczas transmisji danych plikowych.

W toku zajęć szczegółowo analizujemy zależności między uprawnieniami definiowanymi na poziomie usługi (parametry w plikach konfiguracyjnych smb.conf i /etc/exports) a rzeczywistymi uprawnieniami w systemie plików na serwerze (bity trybu POSIX, rozszerzone atrybuty i listy ACL). Niezrozumienie tej relacji stanowi najczęstszą przyczynę krytycznych błędów konfiguracyjnych, prowadzących do nieautoryzowanego dostępu do poufnych zasobów lub całkowitej blokady zapisu dla uprawnionych użytkowników.

Kładziemy szczególny nacisk na bezpieczeństwo teleinformatyczne. Wycofanie podatnego protokołu SMBv1, konfiguracja wymuszonego podpisywania wiadomości (SMB Signing), aktywacja szyfrowania transmisji SMBv3 z algorytmem AES-GCM oraz bezpieczne eksportowanie udziałów NFS z mechanizmem root_squash i uwierzytelnianiem Kerberos (RPCSEC_GSS) stanowią bezwzględny kanon współczesnej administracji siecią LAN.

Wyjaśnienie skrótów i pojęć:
smbd / nmbd – główne demony Samba: obsługa udziałów plików oraz obsługa nazw NetBIOS i przeglądania sieci.
nfs-kernel-server – pakiet serwera NFS w Debian i Ubuntu, realizowany przez jądrowy demon nfsd.
Hardening – proces utwardzania konfiguracji przez usuwanie słabych mechanizmów i wymuszanie silnych zabezpieczeń.
testparm – narzędzie sprawdzające poprawność składni pliku smb.conf przed przeładowaniem usługi.
exportfs / rpcinfo – narzędzia zarządzania eksportami NFS oraz inspekcji zarejestrowanych usług ONC RPC.

Przydatne łącza: Samba (dokumentacja); NFSv4 - RFC 7530; smb.conf (Samba Wiki).

Prezentacja została ustrukturyzowana w sposób umożliwiający płynne przejście od fundamentalnych podstaw teoretycznych protokołów warstwy aplikacji do zaawansowanych zagadnień wdrożeniowych i diagnostycznych. Moduł pierwszy poświęcono w całości technologii SMB oraz implementacji serwera Samba. Omawiamy ewolucję dialektów protokołu, analizując krytyczne zmiany architektoniczne wprowadzone w poszczególnych wersjach, ze szczególnym uwzględnieniem mechanizmów wydajnościowych (SMB Multichannel, SMB Direct) oraz protokołów bezpieczeństwa.

Moduł drugi koncentruje się na standardzie Network File System (NFS). Analizujemy przejście od klasycznego, bezstanowego protokołu NFSv3, silnie uzależnionego od pomocniczych usług RPC (takich jak portmapper/rpcbind, rpc.mountd, lockd/NLM oraz rpc.statd/NSM), do nowoczesnego, w pełni stanowego protokołu NFSv4 i jego rozszerzeń NFSv4.1/4.2. Uczestnicy poznają zasady działania jednolitego pseudo-systemu plików, mechanizm translacji tożsamości oparty na demonie rpc.idmapd oraz równoległą obsługę wejścia/wyjścia za pośrednictwem pNFS.

W części trzeciej prezentujemy scenariusze laboratoryjne, które pozwalają na utrwalenie wiedzy poprzez samodzielną konfigurację udziałów dyskowych w systemie Linux. Końcowe slajdy zawierają usystematyzowaną metodykę diagnozowania usterek (Troubleshooting) w zakresie uprawnień dostępu, blokad sieciowych i niespójności identyfikatorów, a także zwięzłe zestawienia najistotniejszych poleceń administracyjnych.

Wyjaśnienie skrótów i pojęć:
SMB / Samba – protokół współdzielenia plików oraz jego implementacja dla Linux umożliwiająca obsługę stacji Windows.
NFSv3 / NFSv4 – starsza bezstanowa oraz nowsza stanowa wersja protokołu NFS, różniące się portami i modelem bezpieczeństwa.
root_squash – mechanizm mapowania zdalnego administratora na konto anonimowe, podstawowa ochrona serwera NFS.
/etc/fstab / autofs – statyczna tabela montowania oraz demon automatycznego montowania zasobów na żądanie.
Troubleshooting – uporządkowana metodyka diagnozowania usterek od objawu przez przyczynę po weryfikację rozwiązania.

Przydatne łącza: Samba (dokumentacja); NFSv4 - RFC 7530; Microsoft - protokół SMB.

Protokół Server Message Block (SMB) stanowi szkielet komunikacji sieciowej w systemach operacyjnych Microsoft Windows od wczesnych lat 90. XX wieku. Komunikacja w protokole SMB opiera się na wymianie ustrukturyzowanych ramek żądań (Request) i odpowiedzi (Response). Każda operacja plikowa – od otwarcia pliku (SMB_COM_OPEN / SMB2_CREATE), przez odczyt (SMB2_READ) i zapis (SMB2_WRITE), aż po zamknięcie uchwytu (SMB2_CLOSE) – jest precyzyjnie enkapsulowana w nagłówku SMB zawierającym identyfikator sesji (Session ID), identyfikator drzewa udziału (Tree ID) oraz unikalny numer procesu i sekwencji.

Jednym z najważniejszych mechanizmów optymalizacyjnych w protokole SMB są blokady oportunistyczne (ang. opportunistic locks, oplocks). Pozwalają one klientowi założyć, że żaden inny proces w sieci nie modyfikuje danego pliku, co uprawnia klienta do agresywnego buforowania danych w lokalnej pamięci RAM. Dopiero w momencie, gdy drugi klient zgłosi chęć otwarcia tego samego pliku, serwer wysyła do pierwszego klienta komunikat Oplock Break, zmuszając go do natychmiastowego zrzucenia zmodyfikowanych buforów na dysk serwera i przejścia w tryb bezpiecznego dostępu współbieżnego.

W nowszych dialektach (od SMB 2.1) mechanizm ten został zastąpiony znacznie bardziej elastycznym leasingiem plików (Leasing). W odróżnieniu od klasycznych oplocks, leasing pozwala na niezależne przyznawanie uprawnień do buforowania odczytu (Read-caching), zapisu (Write-caching) oraz przetrzymywania uchwytów (Handle-caching), co drastycznie ogranicza ruch sieciowy generowany przez wielokrotne otwieranie i zamykanie tych samych plików przez stacje robocze.

Wyjaśnienie skrótów i pojęć:
Session Setup / Tree Connect – fazy nawiązania sesji uwierzytelnionej oraz dołączenia do konkretnego udziału sieciowego.
Oplocks (opportunistic locks) – blokady oportunistyczne pozwalające klientowi na lokalne buforowanie pliku do czasu odwołania przez serwer.
Leasing (SMB 2.1) – rozszerzenie blokad na niezależne buforowanie odczytu, zapisu i uchwytów plików.
IPC$ (nazwany potok) – ukryty udział administracyjny do komunikacji międzyprocesowej i wywołań RPC.
Samba – kompletna implementacja SMB dla Unix i Linux, zgodna z dialektami negocjowanymi przez Windows.

Przydatne łącza: Microsoft - protokół SMB (MS-SMB2); Samba (dokumentacja).

Protokół SMB w wersji 1 (SMBv1), często utożsamiany z nazwą CIFS (Common Internet File System), powstał w epoce, gdy sieci komputerowe liczyły po kilkanaście stacji roboczych połączonych kablem koncentrycznym, a pojęcie bezpieczeństwa perymetrycznego i zagrożeń kryptograficznych praktycznie nie istniało. W konsekwencji protokół zaprojektowano bez wbudowanych mechanizmów szyfrowania, z archaicznym systemem wymiany haseł LM/NTLMv1 oraz skomplikowaną strukturą ponad 100 komend, z których wiele powielało swoje funkcje w różnych wariantach dialect negotiation.

Z punktu widzenia wydajności sieciowej największą wadą SMBv1 była jego synchroniczna, „przegadana” natura (ang. chatty protocol). Protokół działał w ścisłym reżimie żądanie-odpowiedź: klient wysyłał zapytanie o pojedynczy fragment pliku o maksymalnym rozmiarze 64 KB, po czym musiał bezczynnie oczekiwać na ramkę odpowiedzi serwera przed zainicjowaniem kolejnego odczytu. W sieciach o wysokim iloczynie pasma i opóźnienia (Bandwidth-Delay Product), np. połączeniach międzyoddziałowych WAN, skutkowało to wykorzystaniem zaledwie ułamka dostępnej przepustowości łącza.

Kres zaufania do SMBv1 położyło ujawnienie przez grupę The Shadow Brokers exploita EternalBlue, opracowanego przez amerykańską agencję NSA. Luka ta, sklasyfikowana przez Microsoft jako MS17-010 (CVE-2017-0144), wynikała z błędu przepełnienia bufora podczas parsowania pakietów SMB_COM_TRANSACTION2. Pozwalała ona nieuwierzytelnionemu napastnikowi na zdalne wykonanie dowolnego kodu z uprawnieniami SYSTEM w jądrze Windows. W maju 2017 roku exploit ten posłużył robakowi WannaCry do sparaliżowania setek tysięcy serwerów na całym świecie, wymuszając definitywne wycofanie SMBv1 z nowoczesnych systemów operacyjnych.

Wyjaśnienie skrótów i pojęć:
CIFS – historyczna nazwa SMBv1, obecnie oznaczająca przestarzały i niebezpieczny dialekt.
Chatty protocol – przegadany protokół wymagający potwierdzenia każdej operacji, wrażliwy na opóźnienia sieci.
LM / NTLMv1 – przestarzałe mechanizmy skrótów haseł, podatne na łamanie słownikowe i tablice tęczowe.
EternalBlue (CVE-2017-0144) – exploit zdalnego wykonania kodu w SMBv1, podstawa robaków WannaCry i NotPetya.
MS17-010 – biuletyn Microsoft usuwający lukę EternalBlue, wymagający wyłączenia SMBv1 i instalacji poprawek.

Przydatne łącza: MS-CIFS (specyfikacja); Microsoft - protokół SMB (MS-SMB2).

Wraz z premierą systemu Windows Vista inżynierowie firmy Microsoft podjęli decyzję o całkowitym przepisaniu stosu protokołu SMB od podstaw, tworząc dialekt SMB 2.0. Głównym założeniem projektowym była drastyczna redukcja złożoności architektonicznej protokołu. Zamiast chaotycznego zbioru ponad 100 archaicznych komend SMBv1, wprowadzono zwięzły, 19-komendowy zestaw operacji (m.in. SMB2_NEGOTIATE, SMB2_SESSION_SETUP, SMB2_TREE_CONNECT, SMB2_CREATE, SMB2_READ, SMB2_WRITE). Wszystkie komendy otrzymały ujednolicony, stały 64-bajtowy nagłówek ułatwiający przetwarzanie w pamięci.

Kluczową innowacją SMB 2.0 było wprowadzenie mechanizmu łączenia poleceń (ang. request compounding). W tradycyjnym SMBv1 otwarcie pliku, odczytanie jego zawartości i zamknięcie wymagało co najmniej trzech niezależnych cykli wymiany pakietów sieciowych (Round-Trip Times). W SMB 2.0 klient może połączyć operacje CREATE, READ oraz CLOSE w jeden złożony pakiet, na który serwer odpowiada zbiorczą odpowiedzią. W połączeniu ze zniesieniem ograniczenia bufora do 64 KB i wprowadzeniem sterowania przepływem opartego na kredytach (Credit-based Flow Control), SMBv2 zaoferował kilkudziesięciokrotny wzrost przepustowości w sieciach o wysokich opóźnieniach.

Kolejnym milowym krokiem było wprowadzenie trwałych uchwytów (Durable File Handles). Przed SMB 2.0 chwilowa utrata łączności (np. przełączenie laptopa między siecią Wi-Fi a Ethernet) powodowała natychmiastowe zerwanie sesji, zamknięcie plików na serwerze i awarię aplikacji biurowych. Durable handles pozwalają na przetrwanie krótkotrwałego rozłączenia – serwer zachowuje stan otwartych plików klienta przez określony czas, umożliwiając bezproblemowe wznowienie pracy natychmiast po przywróceniu połączenia TCP.

Wyjaśnienie skrótów i pojęć:
Compounding / Pipelining – łączenie powiązanych operacji w jednej ramce oraz wysyłanie wielu żądań bez oczekiwania na odpowiedzi.
Durable Handles – trwałe uchwyty zachowujące stan otwartych plików podczas krótkiej utraty połączenia.
Credit-based Flow Control – sterowanie przepływem kredytami, dostosowujące liczbę równoległych operacji do możliwości serwera.
MTU (Maximum Transmission Unit) – maksymalny rozmiar jednostki transmisyjnej, wpływający na efektywny rozmiar buforów SMB.
RTT (Round-Trip Time) – czas podróży pakietu w obie strony, kluczowy dla wydajności protokołów synchronicznych.

Przydatne łącza: Microsoft - protokół SMB (MS-SMB2); Samba (dokumentacja).

Dialekt SMB 3.0 (pierwotnie rozwijany pod nazwą SMB 2.2 w systemach Windows 8 i Windows Server 2012) zrewolucjonizował zastosowanie protokołu SMB w centrach przetwarzania danych. Po raz pierwszy protokół plikowy zyskał status pełnoprawnego medium pamięci masowej dla wirtualizatorów Microsoft Hyper-V oraz baz danych Microsoft SQL Server, stając się bezpośrednią konkurencją dla dedykowanych sieci pamięci masowych SAN (Fibre Channel i iSCSI).

Jedną z najbardziej spektakularnych funkcji SMB 3.0 jest SMB Multichannel. Mechanizm ten automatycznie wykrywa obecność wielu interfejsów sieciowych pomiędzy klientem a serwerem, zestawiając równoległe sesje TCP. Jeśli serwer i klient posiadają po dwie karty sieciowe 10 GbE, SMB Multichannel bez udziału mechanizmów agregacji łączy LACP połączy ich przepustowość, osiągając transfer na poziomie 20 Gb/s. W przypadku awarii jednej z kart, ruch zostaje natychmiast i bez zauważalnych przerw przekierowany na pozostałe łącza.

Dla zastosowań o skrajnych wymaganiach wydajnościowych opracowano SMB Direct, wykorzystujący karty sieciowe z obsługą RDMA (Remote Direct Memory Access). Pozwala to na bezpośrednie przesyłanie bloków danych z buforów aplikacji w pamięci RAM klienta do pamięci serwera z pominięciem jądra systemu operacyjnego i stosu TCP/IP. Zapewnia to transfer rzędu dziesiątek gigabajtów na sekundę przy niemal zerowym obciążeniu CPU i mikrosekundowych opóźnieniach.

Najnowszy dialekt SMB 3.1.1 (wprowadzony w Windows 10 i Windows Server 2016) położył fundamentalny nacisk na bezpieczeństwo kryptograficzne. Mechanizm Pre-Authentication Integrity oblicza skrót SHA-512 ze wszystkich pakietów wymienionych podczas wstępnej fazy negocjacji, uniemożliwiając napastnikowi manipulację flagami i wymuszenie podatnego dialektu (atak downgrade). Ponadto wprowadzono szyfrowanie AES-128/256-GCM z obsługą instrukcji AES-NI oraz protokół SMB over QUIC, który enkapsuluje ramki SMB w datagramy UDP na porcie 443, zapewniając bezpieczną telepracę bez konieczności zestawiania tradycyjnych tuneli VPN.

Wyjaśnienie skrótów i pojęć:
AES-CCM / AES-GCM – tryby szyfrowania blokowego zapewniające poufność i integralność transmisji SMB.
SMB Multichannel – automatyczna agregacja wielu połączeń TCP między klientem a serwerem plików.
SMB Direct (RDMA) – bezpośredni dostęp do pamięci zdalnej z pominięciem procesora i stosu TCP.
Transparent Failover – bezprzerwowe przejęcie sesji przez drugi węzeł klastra po awarii.
SMB over QUIC – tunelowanie SMB w protokole QUIC na porcie UDP 443 z TLS 1.3, przeznaczone do pracy zdalnej bez VPN.

Przydatne łącza: Microsoft - protokół SMB (MS-SMB2); Samba (dokumentacja).

Ewolucja warstwy transportowej protokołu SMB odzwierciedla transformację sieci komputerowych na przestrzeni ostatnich dekad. W pierwotnej architekturze systemów Windows for Workgroups i Windows NT protokół SMB nie komunikował się bezpośrednio ze stosem TCP/IP, lecz korzystał z interfejsu NetBIOS (Network Basic Input/Output System). W sieciach routowanych wymagało to zastosowania enkapsulacji NetBIOS over TCP/IP (NBT), zdefiniowanej w dokumentach RFC 1001 i RFC 1002. Sesja SMB była nawiązywana na porcie TCP 139 dopiero po uprzednim odpytaniu usługi nazw NetBIOS (port UDP 137) lub serwera WINS.

Począwszy od systemu Windows 2000, firma Microsoft wprowadziła mechanizm Direct-Hosted SMB pracujący bezpośrednio na porcie TCP 445. W tym modelu wyeliminowano narzut nagłówków NetBIOS – ramka SMB jest poprzedzona jedynie 4-bajtowym polem długości pakietu. Współczesne instalacje serwerów Samba oraz stacji Windows domyślnie komunikują się wyłącznie za pośrednictwem portu TCP 445, co pozwala na całkowite wyłączenie usług NetBIOS w konfiguracji sieciowej i zamknięcie portów UDP 137, 138 oraz TCP 139.

Z punktu widzenia inżynierii bezpieczeństwa port TCP 445 jest jednym z najbardziej newralgicznych portów w sieciach LAN. Wystawienie tego portu na publiczny adres IP w sieci Internet stanowi kardynalny błąd konfiguracyjny, narażający infrastrukturę na natychmiastowe skanowanie przez botnety, ataki brute-force oraz eksploatację niezałatanych podatności w implementacjach protokołu. Standardem branżowym jest bezwzględne odrzucanie ruchu na porcie 445 na wszystkich perymetrycznych zaporach ogniowych (Border Firewalls).

Wyjaśnienie skrótów i pojęć:
TCP 445 – współczesny port bezpośredniego SMB bez NetBIOS, jedyny wymagany w nowych wdrożeniach.
TCP 139 – historyczny port sesji NetBIOS, obecnie wyłączany po migracji na TCP 445.
UDP 137 (NBNS/WINS) – port usługi nazw NetBIOS służący do rozgłoszeniowej rezolucji nazw.
UDP 138 (NetBIOS Datagram) – port datagramów NetBIOS wykorzystywany przez przeglądanie sieci.
ACL / VLAN – lista kontroli dostępu oraz wirtualna sieć lokalna, podstawowe narzędzia segmentacji ruchu SMB.

Przydatne łącza: RFC 1001 (NetBIOS); RFC 1002 (NetBIOS); IANA - numery portów.

Analiza porównawcza poszczególnych generacji protokołu SMB obrazuje przejście od prostego protokołu udostępniania plików w małych sieciach roboczych do zaawansowanego, bezpiecznego standardu korporacyjnego spełniającego rygorystyczne wymagania chmur obliczeniowych i klastrów bazodanowych. Każda nowa wersja dialektu wprowadzała istotne optymalizacje w zakresie minimalizacji narzutu komunikacyjnego oraz podnoszenia poziomu odporności na ataki sieciowe.

Wprowadzenie dialektu SMB 2.0 rozwiązało problem archaicznej struktury komend, a dialekt SMB 2.1 doprecyzował semantykę współbieżnego buforowania danych po stronie stacji roboczych poprzez mechanizm trójstopniowego leasingu (Read, Write, Handle). Dzięki temu stacje robocze pracujące na dużych plikach biurowych przestały bezustannie blokować zasoby serwera przy powtarzających się operacjach sprawdzania metadanych.

Prawdziwym przełomem technologicznym stała się jednak rodzina SMB 3.x. Wbudowane, wydajne szyfrowanie symetryczne AES wyeliminowało konieczność kosztownego i złożonego konfigurowania tuneli IPsec pomiędzy klientami a serwerami plików. SMB Multichannel oraz SMB Direct umożliwiły osiąganie parametrów transmisji zarezerwowanych dotychczas wyłącznie dla dedykowanych architektur Fibre Channel SAN, redukując jednocześnie koszty wdrożenia infrastruktury pamięci masowej w przedsiębiorstwach.

Wyjaśnienie skrótów i pojęć:
NT LM 0.12 – identyfikator dialektu SMBv1 negocjowany przez starsze systemy Windows.
SMB 2.0.2 / 2.1 – dialekty z systemów Vista i Windows 7, wprowadzające uproszczenie poleceń i leasing.
SMB 3.0 / 3.1.1 – dialekty z szyfrowaniem, wielokanałowością oraz ochroną integralności negocjacji.
CA (Continuous Availability) – udziały o ciągłej dostępności, odporne na awarię węzła klastra.
Downgrade – atak wymuszenia starszego dialektu przez manipulację negocjacją, blokowany ochroną pre-authentication.

Przydatne łącza: Microsoft - protokół SMB (MS-SMB2); MS-CIFS (specyfikacja).

Ze względu na powszechność występowania w sieciach korporacyjnych oraz dostęp do newralgicznych danych dyskowych, protokół SMB stanowi jeden z głównych celów zaawansowanych ataków sieciowych. Ataki na środowiska SMB można podzielić na dwie główne kategorie: eksploatację luk w implementacji kodu (takich jak podatności typu Remote Code Execution w demonach SMB) oraz ataki wykorzystujące słabości protokołów uwierzytelniania legacy, w szczególności mechanizmu NTLM (NT LAN Manager).

Jednym z najgroźniejszych wektorów ataku w sieciach wewnętrznych jest atak typu SMB Relay. W scenariuszu tym napastnik, korzystając z narzędzi takich jak Responder, nasłuchuje na rozgłoszenia LLMNR/mDNS lub zatruwa tablice ARP, prowokując stację roboczą ofiary do próby połączenia i przesłania wyzwania uwierzytelniającego NTLM. Zamiast łamać przechwycony skrót, napastnik w czasie rzeczywistym przekazuje te dane do innego serwera w sieci, uzyskując nieautoryzowaną sesję z uprawnieniami ofiary. Jedyną skuteczną metodą neutralizacji ataku SMB Relay na poziomie protokołu jest wymuszenie kryptograficznego podpisywania pakietów (server signing = mandatory w Sambie lub odpowiednia polisa GPO w Windows).

Skuteczna obrona środowiska SMB wymaga wdrożenia wielowarstwowej strategii bezpieczeństwa (Defense in Depth). Obejmuje ona: bezwzględne wyłączenie dialektu SMBv1 na wszystkich maszynach, wymuszenie podpisywania pakietów SMB, aktywację szyfrowania transmisji SMBv3 dla newralgicznych udziałów, wyłączenie rozgłoszeń LLMNR i NetBIOS na stacjach klienckich oraz ścisłe monitorowanie dzienników zdarzeń pod kątem anomalii w uwierzytelnianiu (np. zdarzenia Microsoft-Windows-SMBServer/Operational).

Wyjaśnienie skrótów i pojęć:
Pass-the-Hash – atak logowania przechwyconym skrótem NTLM bez znajomości hasła jawnego.
SMB Relay – atak przekazania sesji NTLM do innego serwera w celu uzyskania nieautoryzowanego dostępu.
SMB Signing – kryptograficzne podpisywanie pakietów, podstawowa ochrona przed atakami typu relay.
LLMNR / NBT-NS – protokoły rozgłoszeniowej rezolucji nazw, często wykorzystywane przez narzędzia Responder.
LAPS / Credential Guard – mechanizmy rotacji haseł lokalnych oraz izolacji poświadczeń w systemie Windows.

Przydatne łącza: Samba (dokumentacja); Microsoft - protokół SMB (MS-SMB2).

Precyzyjna identyfikacja aktywnych dialektów protokołu SMB w infrastrukturze sieciowej jest podstawowym obowiązkiem administratora dbającego o bezpieczeństwo systemów. W środowisku Windows Server oraz stacjach roboczych Windows 10/11 podstawowym narzędziem audytowym jest moduł SmbShare środowiska PowerShell. Polecenie Get-SmbServerConfiguration zwraca szczegółowy profil usługi serwera SMB, w tym parametry logiczne określające aktywność poszczególnych dialektów. Aby z poziomu stacji roboczej sprawdzić, który dialekt został wynegocjowany z docelowym serwerem plików, wykorzystuje się polecenie Get-SmbConnection, zwracające adres serwera, nazwę udziału oraz dokładną wersję protokołu (np. 3.1.1) i algorytm szyfrowania.

W środowiskach linuksowych opartych na pakiecie Samba za dopuszczalny zakres dialektów odpowiadają dyrektywy server min protocol oraz server max protocol zdefiniowane w sekcji [global] pliku konfiguracyjnego smb.conf. Domyślne wartości tych parametrów można w każdej chwili zweryfikować za pomocą polecenia testparm -v, które parsuje bieżącą konfigurację i wyświetla wszystkie niejawne wartości domyślne kompilacji. Aby zablokować przestarzały protokół SMBv1, należy jawnie ustawić wartość server min protocol = SMB2_02 (lub SMB2).

Z punktu widzenia audytora sieciowego niezastąpionym narzędziem weryfikacji zewnętrznej jest skaner Nmap z dedykowanym skryptem silnika NSE: smb-protocols. Skrypt ten nawiązuje sesję z portem TCP 445 i analizuje pakiety negocjacji dialektów (SMB Negotiate), raportując pełną listę wersji protokołu akceptowanych przez badany serwer bez konieczności posiadania konta w domenie.

Wyjaśnienie skrótów i pojęć:
Get-SmbConnection – polecenie PowerShell pokazujące aktywne sesje SMB wraz z kolumną Dialect.
server min protocol – dyrektywa smb.conf określająca najniższy dopuszczalny dialekt, zalecana wartość SMB2_02.
smbclient -m – opcja wymuszenia dialektu podczas testu klienta Linux, na przykład -m SMB3.
Nmap smb-protocols – skrypt NSE raportujący listę dialektów akceptowanych przez serwer na porcie 445.
Dialect – numer wersji protokołu wynegocjowany dla danej sesji, na przykład 2.1, 3.0 albo 3.1.1.

Przydatne łącza: Microsoft - protokół SMB (MS-SMB2); smb.conf (Samba Wiki).

Całkowite wyeliminowanie protokołu SMBv1 z produkcyjnej infrastruktury korporacyjnej wymaga zdyscyplinowanego podejścia metodycznego. Nagłe wyłączenie usługi bez uprzedniej inwentaryzacji niemal zawsze prowadzi do paraliżu procesów biznesowych, w szczególności funkcji sieciowego skanowania dokumentów w urządzeniach wielofunkcyjnych (MFP) czy automatycznego tworzenia kopii zapasowych przez starsze kontrolery przemysłowe lub macierze NAS.

Pierwszym krokiem jest wdrożenie cichego audytu na wszystkich serwerach plików. W środowisku Windows Server służy do tego polecenie PowerShell Set-SmbServerConfiguration -AuditSmb1Access $true. Włącza ono rejestrację zdarzeń w dedykowanym kanale Applications and Services Logs / Microsoft / Windows / SMBServer / Audit. Kluczowe znaczenie ma zdarzenie o identyfikatorze Event ID 1001, które pojawia się za każdym razem, gdy dowolny host próbuje nawiązać sesję przy użyciu dialektu SMBv1. Log ten precyzyjnie wskazuje źródłowy adres IP klienta oraz nazwę żądanego konta użytkownika.

Po zgromadzeniu danych z okresu audytu (trwającego zazwyczaj od kilkunastu dni do miesiąca) administratorzy przeprowadzają inwentaryzację urządzeń generujących ruch legacy. W pierwszej kolejności aktualizuje się oprogramowanie układowe (firmware) skanerów i drukarek biurowych. Jeśli producent sprzętu nie udostępnił aktualizacji wprowadzającej obsługę SMBv2 lub SMBv3, optymalnym rozwiązaniem inżynierskim jest zmiana protokołu przesyłania skanów na bezpieczny protokół SFTP/FTPS lub skierowanie ruchu do dedykowanego, wyizolowanego serwera pośredniczącego (bastion proxy) umieszczonego w ściśle monitorowanym segmencie sieci VLAN.

Dopiero po upewnieniu się, że żaden kluczowy system nie generuje zdarzeń Event ID 1001, następuje faza administracyjnego wyłączenia protokołu za pośrednictwem zasad grupy Active Directory (GPO), polecenia PowerShell Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol oraz dyrektywy server min protocol = SMB2_02 w plikach konfiguracyjnych serwerów Samba.

Wyjaśnienie skrótów i pojęć:
AuditSmb1Access – opcja rejestrowania prób nawiązania sesji SMBv1 na serwerze Windows.
Event ID 1001 – zdarzenie dziennika SMBServer Audit wskazujące adres klienta używającego SMBv1.
MFP (urządzenie wielofunkcyjne) – drukarka ze skanerem, częste źródło ruchu legacy z powodu starego oprogramowania.
VLAN (Virtual LAN) – logiczna sieć wirtualna służąca do izolacji urządzeń nieobsługujących nowych dialektów.
GPO (Group Policy Object) – obiekt zasad grupy umożliwiający centralne wymuszenie wyłączenia SMBv1 w domenie.

Przydatne łącza: Microsoft - protokół SMB (MS-SMB2); Samba (dokumentacja).

Pakiet oprogramowania Samba stanowi jeden z najważniejszych filarów interoperacyjności w historii teleinformatyki. Gdy Andrew Tridgell w 1991 roku napisał prosty program sniffera pakietów w celu połączenia komputera PC z serwerem DEC pod kontrolą systemu Unix, protokół SMB był zamkniętą technologią własnościową. Drobiazgowa analiza pakietów binarnych pozwoliła na odtworzenie specyfikacji protokołu i stworzenie oprogramowania, które dziś stanowi fundament heterogenicznych sieci korporacyjnych na całym świecie.

Współczesna architektura serwera Samba w tradycyjnej roli serwera plików (Member Server lub Standalone Server) opiera się na dwóch podstawowych demonach systemowych: smbd oraz nmbd. Demon smbd odpowiada za właściwą wymianę danych plikowych, uwierzytelnianie użytkowników, zarządzanie prawami dostępu do udziałów oraz kontrolowanie blokad współbieżnych. Demon ten nasłuchuje na porcie 445/TCP oraz opcjonalnie 139/TCP. Z kolei nmbd jest demonem pomocniczym, obsługującym historyczne mechanizmy NetBIOS over TCP/IP na portach UDP 137 i 138; w nowoczesnych, dobrze zaprojektowanych sieciach pozbawionych zależności NetBIOS, demon nmbd może zostać całkowicie wyłączony.

Trzecim krytycznym komponentem, szczególnie w środowiskach zintegrowanych z Microsoft Windows Server, jest demon winbindd. Odpowiada on za pobieranie informacji o użytkownikach i grupach z kontrolera domeny Active Directory i udostępnianie ich systemowi Linux za pośrednictwem standardowego interfejsu NSS (Name Service Switch). Dzięki temu pliki na partycji linuksowej ext4 lub XFS mogą mieć przypisanych jako właścicieli użytkowników domenowych, zachowując pełną spójność uprawnień pomiędzy systemami Windows i Linux.

Wyjaśnienie skrótów i pojęć:
smbd – główny demon obsługi plików, sesji i blokad w protokole SMB.
nmbd – demon obsługi nazw NetBIOS i przeglądania sieci, zbędny po migracji na TCP 445.
winbindd – demon mapujący konta domenowe SID na uniksowe identyfikatory UID i GID.
AD DC (kontroler domeny) – serwer usługi katalogowej Active Directory, możliwy do realizacji przez Samba 4.
Reverse Engineering – inżynieria wsteczna polegająca na odtworzeniu protokołu na podstawie analizy pakietów.

Przydatne łącza: Samba (dokumentacja); smb.conf (Samba Wiki).

Sercem konfiguracji serwera Samba jest plik /etc/samba/smb.conf. Plik ten jest interpretowany dynamicznie przez demony smbd oraz narzędzia administracyjne. Składa się z sekcji wyróżnionych nawiasami kwadratowymi, po których następują dyrektywy konfiguracyjne w postaci parametr = wartość. Wszelkie linie rozpoczynające się od znaku średnika (;) lub krzyżyka (#) są traktowane jako komentarze.

Sekcja [global] jest obowiązkowa i unikalna – występuje w pliku dokładnie jeden raz. Definiuje ona fundamentalne zachowanie serwera w sieci. Parametr workgroup określa nazwę grupy roboczej lub domeny Windows, do której serwer należy. Dyrektywa security = user informuje, że uwierzytelnianie odbywa się na poziomie użytkownika (użytkownik musi podać login i hasło, aby uzyskać token dostępu). Parametry takie jak server min protocol chronią infrastrukturę przed negocjacją podatnych dialektów, a passdb backend = tdbsam wskazuje format bazy danych przechowującej skróty poświadczeń SMB.

Pozostałe sekcje definiują udziały dyskowe. Szczególną rolę odgrywa wbudowana sekcja [homes]. Gdy użytkownik (np. student) łączy się z zasobem \\serwer\student, a udział o takiej nazwie nie istnieje wprost w konfiguracji, Samba sprawdza sekcję [homes]. Jeśli zapytanie jest poprawne, serwer dynamicznie tworzy w pamięci instancję udziału wskazującą na katalog domowy użytkownika (np. /home/student), zapewniając izolację i automatyzację dostępu bez konieczności ręcznego definiowania setek wpisów w konfiguracji.

Wyjaśnienie skrótów i pojęć:
Sekcja [global] – jedyna sekcja wspólna definiująca zachowanie całego serwera Samba.
security = user – model wymuszający uwierzytelnianie loginem i hasłem dla każdego połączenia.
passdb backend = tdbsam – backend bazy haseł NTLM w pliku binarnym passdb.tdb.
Sekcja [homes] – dynamiczny udział udostępniający katalog domowy łączącego się użytkownika.
testparm – walidator składni pliku smb.conf, obowiązkowy przed przeładowaniem usługi.

Przydatne łącza: smb.conf (Samba Wiki); Samba (dokumentacja).

Jednym z najczęstszych nieporozumień wśród początkujących administratorów systemów Linux jest założenie, że hasło wprowadzone przez użytkownika podczas logowania do powłoki bash zadziała automatycznie przy próbie połączenia z udziałem Samba. Jest to technicznie niemożliwe ze względu na specyfikę protokołu SMB oraz architekturę bezpieczeństwa jądra Linux.

Systemy uniksowe przechowują w pliku /etc/shadow skróty haseł generowane przez zaawansowane, odporne na łamanie algorytmy kryptograficzne (np. SHA-512 z dynamiczną solą lub yescrypt). Protokoły uwierzytelniania rodziny SMB (NTLMv2) wymagają natomiast operowania na specyficznym skrócie NTLM, który jest wynikiem funkcji skrótu MD4 obliczonej z hasła zakodowanego w formacie Unicode UTF-16LE. Ponieważ z bezpiecznego skrótu w /etc/shadow nie da się odtworzyć hasła jawnego, serwer Samba musi posiadać własny, chroniony magazyn skrótów NTLM.

Współczesnym standardem przechowywania danych uwierzytelniających w Sambie jest baza Trivial Database (TDB), określana parametrem passdb backend = tdbsam. Plik bazy passdb.tdb znajduje się w odizolowanym katalogu /var/lib/samba/private/ z prawami dostępu zastrzeżonymi wyłącznie dla konta root. Do zarządzania tą bazą służy tradycyjne polecenie smbpasswd oraz nowoczesne, wysoce zalecane narzędzie pdbedit. Narzędzie pdbedit pozwala nie tylko na tworzenie i usuwanie tożsamości, lecz również na manipulację zaawansowanymi atrybutami SAM (Security Account Manager), takimi jak wygasanie haseł, blokady kont, czy przypisywanie identyfikatorów RID i profili użytkowników.

Wyjaśnienie skrótów i pojęć:
NTLM (skrót) – skrót MD4 z hasła w UTF-16LE, wymagany przez uwierzytelnianie SMB.
/etc/shadow – systemowy plik skrótów haseł Linux z solą i funkcjami SHA-512 albo yescrypt.
tdbsam – backend prostej bazy danych TDB przechowującej konta i skróty Samba.
smbpasswd – klasyczne narzędzie dodawania i zmiany haseł SMB dla użytkowników.
pdbedit – nowoczesne narzędzie zarządzania bazą SAM, listowania flag i atrybutów kont.

Przydatne łącza: Samba (dokumentacja); smb.conf (Samba Wiki).

Definiowanie udziałów sieciowych w pliku smb.conf wymaga dogłębnego zrozumienia dwupoziomowego modelu kontroli dostępu. Każde żądanie odczytu lub zapisu wysyłane przez klienta SMB musi przejść przez dwa niezależne filtry: uprawnienia zdefiniowane w konfiguracji usługi Samba (Share-level Permissions) oraz fizyczne uprawnienia obowiązujące w lokalnym systemie plików serwera (File System Permissions – POSIX/ACL). Jeśli którykolwiek z tych poziomów odmówi dostępu, operacja klienta zostanie zablokowana.

W sekcji udziału dyrektywa path definiuje docelowy punkt montowania w drzewie katalogów. Parametry read only = no oraz writable = yes są semantycznie tożsame i decydują o tym, czy Samba w ogóle zezwoli na wykonywanie operacji modyfikacji danych. Kluczowym parametrem bezpieczeństwa jest valid users, który przyjmuje listę nazw użytkowników rozdzielonych przecinkami lub spacjami; prefiks małpy (@grupa) oznacza odwołanie do lokalnej lub domenowej grupy systemowej. Parametr write list pozwala na stworzenie udziału, w którym większość pracowników posiada dostęp wyłącznie do odczytu (np. biblioteka procedur firmowych), podczas gdy wyznaczeni redaktorzy mogą modyfikować treść dokumentów.

Niezwykle istotną rolę pełnią parametry create mask oraz directory mask. Kiedy klient Windows tworzy nowy plik, operuje na atrybutach DOS/NTFS (Read-only, Archive, Hidden, System). Samba musi przetłumaczyć te operacje na standardowe bity uprawnień POSIX (rwxrwxrwx). Parametry maski stanowią logiczny iloczyn bitowy (AND), gwarantując, że żaden użytkownik nie utworzy w udziale pliku o niebezpiecznych uprawnieniach (np. z powszechnym prawem wykonania lub zapisu dla wszystkich użytkowników systemu operacyjnego).

Wyjaśnienie skrótów i pojęć:
path – bezwzględna ścieżka katalogu udostępnianego w lokalnym systemie plików.
valid users – ścisła lista użytkowników i grup uprawnionych do połączenia z udziałem.
write list – lista użytkowników z prawem zapisu w udziale domyślnie tylko do odczytu.
create mask / directory mask – maski bitowe uprawnień POSIX dla nowych plików i katalogów.
force user – wymuszenie zapisu wszystkich plików z tożsamością wskazanego konta systemowego.

Przydatne łącza: smb.conf (Samba Wiki); Samba (dokumentacja).

Przedstawiony listing stanowi kompletny, bezpieczny szkielet konfiguracyjny serwera plików Samba, odpowiadający współczesnym standardom teleinformatycznym. W sekcji [global] zdefiniowano nazwę grupy roboczej ASKLAB oraz czytelny opis serwera widoczny w otoczeniu sieciowym. Wdrożenie parametru security = user wymusza uwierzytelnianie każdego połączenia, a dyrektywa server min protocol = SMB2_02 całkowicie uniemożliwia negocjację podatnego dialektu SMBv1. Dodatkowo wymuszono cyfrowe podpisywanie pakietów (server signing = mandatory), co skutecznie chroni serwer przed atakami typu SMB Relay i podszywaniem się pod sesję.

Zmienna log file = /var/log/samba/log.%m to przykład wykorzystania makr Samby. Makro %m zostaje automatycznie zastąpione nazwą stacji roboczej klienta NetBIOS. W efekcie każde urządzenie łączące się z serwerem otrzymuje swój dedykowany, odrębny plik dziennika zdarzeń (np. log.laptop-prezesa), co radykalnie ułatwia audyt bezpieczeństwa i debugowanie problemów w dużych sieciach korporacyjnych.

W sekcjach udziałów zestawiono dwa przeciwstawne modele dostępu. Udział [Publiczny] jest w pełni anonimowy (guest ok = yes), ale zabezpieczony przed przypadkowym lub złośliwym skasowaniem danych poprzez wymuszenie trybu tylko do odczytu (read only = yes). Z kolei udział [Prywatny] to zasób o wysokich wymaganiach poufności: dostęp anonimowy jest zablokowany, sesje mogą nawiązywać wyłącznie członkowie grupy pracownicy, a maski create mask = 0660 i directory mask = 0770 gwarantują, że nowo tworzone pliki będą zawsze dostępne dla pozostałych członków zespołu, uniemożliwiając jednocześnie jakikolwiek odczyt użytkownikom spoza grupy.

Wyjaśnienie skrótów i pojęć:
server min protocol – minimalny dialekt akceptowany przez serwer, blokada SMBv1 przez wartość SMB2_02.
server signing – wymóg podpisywania pakietów, ochrona przed atakami typu relay przy wartości mandatory.
%m (makro) – makro zastępowane nazwą NetBIOS stacji klienckiej w ścieżce dziennika.
guest ok – zezwolenie na dostęp anonimowy, bezpieczne wyłącznie z trybem tylko do odczytu.
create mask 0660 – maska zapewniająca odczyt i zapis dla właściciela i grupy przy braku dostępu innych.

Przydatne łącza: smb.conf (Samba Wiki); Samba (dokumentacja).

Efektywne zarządzanie serwerem Samba w środowisku produkcyjnym wymaga biegłości w posługiwaniu się zestawem wyspecjalizowanych narzędzi konsolowych wchodzących w skład pakietu. Każde z tych poleceń pełni unikalną rolę w cyklu życia usługi – od etapu projektowania konfiguracji, przez codzienne monitorowanie obciążenia, aż po zaawansowaną diagnostykę awarii.

Podstawowym poleceniem, od którego administrator musi bezwzględnie rozpocząć każdą ingerencję w plik konfiguracyjny, jest testparm. Program ten wczytuje plik /etc/samba/smb.conf, przeprowadza drobiazgową analizę syntaktyczną i semantyczną oraz weryfikuje istnienie ścieżek zadeklarowanych w dyrektywach path. Uruchomiony z przełącznikiem -s wyświetla czystą, zwięzłą konfigurację pozbawioną zbędnych komentarzy. Restart usługi smbd bez uprzedniego wykonania testparm stanowi poważny błąd w sztuce administratorskiej.

Z kolei polecenie smbstatus to główne okno wglądu w bieżącą aktywność serwera. Korzystając bezpośrednio z wewnętrznych struktur baz danych TDB (takich jak sessionid.tdb i locking.tdb), raportuje ono podział na trzy sekcje: aktywne połączenia sieciowe (z podaniem PID procesu roboczego, konta użytkownika, grupy i adresu IP), aktualnie zamontowane udziały oraz listę wszystkich otwartych plików z precyzyjnym wskazaniem trybu blokady (Exclusive, Batch, Lease). Pozwala to administratorowi błyskawicznie zidentyfikować, który użytkownik blokuje współdzielony arkusz kalkulacyjny lub plik bazy danych.

Wyjaśnienie skrótów i pojęć:
testparm -s – walidator składni wyświetlający oczyszczoną konfigurację bez komentarzy.
smbstatus – monitor sesji, udziałów, otwartych plików i blokad w czasie rzeczywistym.
smbclient – klient wiersza poleceń do listowania udziałów i testów dostępu.
net – wielofunkcyjne narzędzie administracyjne do zarządzania usługą i domeną.
TDB (Trivial Database) – prosta baza danych Samba przechowująca sesje, blokady i konta.

Przydatne łącza: Samba (dokumentacja); smb.conf (Samba Wiki).

Integracja serwera linuksowego z usługą katalogową Microsoft Active Directory Domain Services (AD DS) w roli serwera członkowskiego (Domain Member) jest standardem w dojrzałych środowiskach korporacyjnych. Pozwala ona na wyeliminowanie redundancji kont użytkowników – tożsamości, hasła oraz grupy są zarządzane centralnie na kontrolerach domeny, podczas gdy Linux udostępnia przestrzeń dyskową, zachowując pełne respektowanie domenowych list kontroli dostępu.

Proces integracji jest wieloetapowy i rygorystyczny. Protokół Kerberos v5, będący fundamentem uwierzytelniania w Active Directory, opiera się na kryptograficznych biletach czasowych (Time Tickets). Jeśli zegar systemowy serwera Samba rozbiegnie się z zegarem kontrolera domeny o więcej niż dopuszczalne okno skośności (domyślnie 300 sekund), generowanie biletów zakończy się błędem KRB5KRB_AP_ERR_SKEW. Dlatego wdrożenie i stały nadzór nad demonem synchronizacji czasu (Chrony lub systemd-timesyncd) jest krytycznym warunkiem stabilności środowiska.

Niezwykle istotnym zagadnieniem architektonicznym jest translacja identyfikatorów zabezpieczeń SID (Security Identifiers) używanych przez Windows na uniksowe numery UID i GID. Odpowiada za to demon winbindd oraz skonfigurowany w smb.conf podsystem idmap. Wybór backendu (np. idmap config DOMENA : backend = rid lub autorid) determinuje, w jaki sposób 32-bitowy identyfikator RID z tokenu użytkownika jest przekształcany na lokalny UID. Prawidłowa konfiguracja zapewnia, że dany użytkownik domenowy uzyska identyczny UID na wszystkich serwerach linuksowych w przedsiębiorstwie, co ma fundamentalne znaczenie przy jednoczesnym współdzieleniu zasobów przez protokoły SMB i NFS.

Wyjaśnienie skrótów i pojęć:
AD DS – usługi domenowe Active Directory, centralna baza tożsamości, haseł i grup.
Kerberos v5 – protokół biletów czasowych, fundament uwierzytelniania w domenie Windows.
realm – nazwa sfery Kerberos, zwykle równoważna nazwie DNS domeny zapisaną wielkimi literami.
idmap (RID / autorid) – podsystem mapowania identyfikatorów SID na uniksowe UID i GID.
net ads join – polecenie dołączające serwer Samba do domeny Active Directory.

Przydatne łącza: Samba (dokumentacja); smb.conf (Samba Wiki).

Systematyczna i metodyczna diagnostyka serwera Samba wymaga precyzyjnego operowania mechanizmami rejestracji zdarzeń. Domyślny poziom logowania (poziom 0 lub 1) jest zoptymalizowany pod kątem minimalizacji obciążenia operacjami I/O dysków serwera i rejestruje jedynie zdarzenia o charakterze krytycznym, takie jak awarie demonów czy błędy integralności baz TDB. Podczas rozwiązywania problemów z uwierzytelnianiem użytkowników lub odmową dostępu do plików poziom ten okazuje się jednak niewystarczający.

Zwiększenie parametru log level do wartości 2 lub 3 w sekcji [global] dostarcza inżynierowi kluczowych informacji o przebiegu negocjacji sesji, wybranym dialekcie oraz powodach odrzucenia tokenu uwierzytelniającego (np. NT_STATUS_WRONG_PASSWORD lub NT_STATUS_NO_SUCH_USER). Nowoczesne wersje Samby pozwalają na selektywne podnoszenie szczegółowości logów dla wybranych klas podsystemu, np. log level = 1 auth:3 passdb:3 vfs:2. Dzięki temu administrator unika zalania dzienników gigabajtami zbędnych informacji o każdym przesłanym pakiecie, koncentrując się bezpośrednio na module generującym problem.

Jeżeli logi serwera nie wskazują jednoznacznej przyczyny usterki (np. połączenie ze stacji klienckiej zawiesza się przed etapem uwierzytelnienia), kolejnym etapem analizy jest inspekcja warstwy sieciowej za pomocą sniffera pakietów tcpdump -i any port 445 -nn -s0 -w /tmp/samba_debug.pcap. Otwarcie wygenerowanego pliku w programie Wireshark pozwala na drobiazgowe prześledzenie sekwencji TCP hand-shake, wymiany komunikatów SMB2 NEGOTIATE i wykrycie ewentualnych blokad na pośredniczących zaporach sieciowych lub mechanizmach inspekcji pakietów (Deep Packet Inspection).

Wyjaśnienie skrótów i pojęć:
log level – poziom szczegółowości dzienników od 0 dla produkcji po 10 dla analizy laboratoryjnej.
/var/log/samba/ – główny katalog dzienników serwera Samba w systemie Linux.
journalctl -u smbd – podgląd zdarzeń usługi w dzienniku systemd z filtrem jednostki.
ss -tulpn – polecenie listujące gniazda TCP i UDP wraz z procesami i numerami portów.
smbclient //localhost/udzial – lokalny test uwierzytelniania eliminujący wpływ zapory i sieci.

Przydatne łącza: Samba (dokumentacja); smb.conf (Samba Wiki).

Network File System (NFS) to bezsprzecznie najważniejszy protokół sieciowego współdzielenia danych w historii systemów klasy Unix i Linux. Zaprojektowany przez inżynierów Sun Microsystems pod kierownictwem Billa Joya, od samego początku powstawał jako technologia otwarta i niezależna od konkretnej architektury sprzętowej. Opublikowanie specyfikacji protokołu w formacie RFC umożliwiło jego błyskawiczną implementację we wszystkich komercyjnych odmianach Uniksa (takich jak IBM AIX, HP-UX, SGI IRIX) oraz systemach BSD i Linux.

Fundamentalnym atutem NFS jest jego organiczna integracja z warstwą wirtualnego systemu plików (Virtual File System – VFS) jądra uniksowego. Gdy proces użytkownika wykonuje standardowe wywołanie systemowe (np. read() na deskryptorze pliku), podsystem VFS kieruje to żądanie do sterownika systemu plików NFS. Sterownik tłumaczy operację POSIX na procedurę sieciową RPC, serializuje parametry przy użyciu standardu XDR (External Data Representation, RFC 4506) i przesyła pakiet przez sieć do serwera. Po odebraniu odpowiedzi dane trafiają bezpośrednio do bufora procesu w przestrzeni użytkownika. Z punktu widzenia oprogramowania (np. serwera baz danych lub środowiska kompilacji) praca na zdalnym zasobie NFS jest całkowicie nieodróżnialna od operacji na lokalnym dysku twardym NVMe lub SATA.

Dzięki bezpośredniej zgodności z uniksową semantyką uprawnień (prawa rwxrwxrwx, dowiązania twarde i symboliczne, pliki specjalne urządzeń i nazwane potoki FIFO), NFS stał się bezkonkurencyjnym standardem w farmach serwerów obliczeniowych, laboratoriach akademickich oraz wielowęzłowych klastrach wirtualizacyjnych. Pozwala na centralizację danych bez narzutu emulacji środowiska Windows, który występuje w przypadku protokołu SMB.

Wyjaśnienie skrótów i pojęć:
Sun Microsystems – producent systemów Unix, twórca protokołu NFS i architektury ONC.
VFS (Virtual File System) – warstwa jądra kierująca wywołania plikowe do właściwego sterownika systemu plików.
ONC RPC – mechanizm zdalnego wywoływania procedur, fundament komunikacji NFS.
XDR (External Data Representation) – format serializacji danych w RPC, opisany w RFC 4506.
HPC / PXE – klastry obliczeniowe oraz sieciowy rozruch stacji bezdyskowych, typowe zastosowania NFS.

Przydatne łącza: NFSv4 - RFC 7530; NFSv3 - RFC 1813; ONC RPC - RFC 5531.

Klasyczna architektura protokołu NFS (w wersjach NFSv2 oraz NFSv3) jest nierozerwalnie związana z mechanizmem zdalnego wywoływania procedur Open Network Computing Remote Procedure Call (ONC RPC). Zamiast projektować dedykowany protokół transportowy dla każdej operacji plikowej, inżynierowie zdefiniowali zestaw procedur RPC, które klient wywołuje na serwerze, przekazując argumenty i odbierając wyniki w znormalizowanym, binarnym formacie kodowania XDR (External Data Representation).

Ponieważ system operacyjny może uruchamiać dziesiątki różnych usług RPC, z których każda w chwili startu pobiera losowy, wolny port z puli efemerycznej jądra, niezbędne było wprowadzenie centralnej książki telefonicznej. Rolę tę pełni usługa rpcbind (w starszych wersjach systemów uniksowych znana jako portmapper), pracująca na stałym, zarejestrowanym porcie TCP i UDP 111. Podczas uruchamiania serwera NFS poszczególne demony (nfsd, rpc.mountd, lockd, rpc.statd) kontaktują się lokalnie z rpcbind i rejestrują swój unikalny numer programu RPC (np. 100003 dla NFS, 100005 dla MOUNT), obsługiwane wersje protokołu oraz przydzielony numer portu TCP/UDP.

Gdy klient NFSv3 zamierza zamontować udział, nie łączy się od razu z portem 2049, lecz w pierwszej kolejności wysyła zapytanie RPC na port 111 serwera, pytając o numer portu demona mountd. Po uzyskaniu odpowiedzi klient nawiązuje połączenie z demonem mountd, pobiera uchwyt plikowy (File Handle) głównego katalogu, a następnie ponownie odpytuje rpcbind o port właściwego demona nfsd. Podstawowym narzędziem diagnostycznym administratora w tej architekturze jest polecenie rpcinfo -p, które wyświetla pełną tabelę zarejestrowanych programów RPC, wersji oraz portów nasłuchiwania.

Wyjaśnienie skrótów i pojęć:
portmapper – historyczna nazwa usługi rpcbind w starszych systemach Unix.
TCP/UDP 111 – dobrze znany port rejestru rpcbind, wymagany dla klienta NFSv3.
nfsd (100003) – właściwy demon plików NFS, zwykle na porcie TCP i UDP 2049.
mountd (100005) – demon weryfikacji montowania, w NFSv3 na porcie dynamicznym.
rpcinfo -p – polecenie listujące zarejestrowane programy RPC, wersje i porty.

Przydatne łącza: ONC RPC - RFC 5531; XDR - RFC 4506; NFSv3 - RFC 1813.

Historia protokołu NFS stanowi fascynujący przykład ewolucji oprogramowania sieciowego dostosowującego się do gwałtownie rosnących wymagań dotyczących pojemności pamięci masowych, przepustowości sieci i bezpieczeństwa kryptograficznego. Protokół NFSv2, opisany w RFC 1094, był rozwiązaniem pionierskim, lecz posiadał fundamentalne ograniczenia architektoniczne: 32-bitowe pola długości uniemożliwiały obsługę plików większych niż 2 GB, a praca wyłącznie na bezpołączeniowym protokole UDP powodowała masową utratę pakietów i drastyczny spadek wydajności w sieciach z trasowaniem pakietów.

Opublikowany w 1995 roku standard NFSv3 (RFC 1813) rozwiązał te bolączki. Wprowadzenie 64-bitowych struktur przesunięcia otworzyło drogę do obsługi plików o rozmiarach rzędu terabajtów. Dodanie natywnej obsługi protokołu TCP w warstwie transportowej zapewniło niezawodną retransmisję pakietów w sieciach WAN. Ponadto wprowadzono operację asynchronicznego zapisu (asynchronous write) wraz z poleceniem COMMIT – serwer mógł natychmiast potwierdzić odbiór danych po zapisaniu ich do pamięci podręcznej (RAM cache), a klient w dogodnym momencie wymuszał fizyczne utrwalenie danych na nośniku dyskowym, co przyniosło wielokrotny wzrost prędkości zapisu.

Prawdziwą rewolucją okazało się jednak opracowanie standardu NFSv4 pod egidą IETF (początkowo RFC 3530, obecnie skonsolidowane w RFC 7530). Odrzucono w nim historyczny balast bezstanowości oraz rozproszonych pomocniczych demonów RPC. NFSv4 stał się protokołem całkowicie stanowym, komunikującym się przez jeden port TCP 2049, wyposażonym w natywne mechanizmy negocjacji sesji, blokowania plików, leasingu oraz zintegrowane bezpieczeństwo kryptograficzne RPCSEC_GSS. Kolejne rozszerzenia – NFSv4.1 (pNFS) oraz NFSv4.2 (Server-Side Copy, alokacja bloków, Labeled NFS dla systemów z SELinux) – uczyniły z NFS potężne narzędzie zdolne do zasilania najbardziej wymagających centrów danych i chmur obliczeniowych.

Wyjaśnienie skrótów i pojęć:
NFSv2 – pierwszy standard z 1989 roku, wyłącznie UDP i synchroniczny zapis.
NFSv3 – wersja z 1995 roku z TCP, asynchronicznym zapisem i operacją COMMIT.
NFSv4.0 – wersja stanowa z jednym portem, leasingiem i listami NFSv4 ACL.
pNFS (Parallel NFS) – rozszerzenie 4.1 umożliwiające równoległy transfer z wielu serwerów danych.
NFSv4.2 – rozszerzenie z kopiowaniem serwerowym, plikami rzadkimi i etykietami SELinux.

Przydatne łącza: NFSv2 - RFC 1094; NFSv3 - RFC 1813; NFSv4 - RFC 7530; NFSv4.2 - RFC 7862.

Porównanie protokołów NFSv3 i NFSv4 ukazuje fundamentalną zmianę paradygmatu w projektowaniu sieciowych systemów plików. W NFSv3 naczelną zasadą była bezstanowość serwera (statelessness): serwer nie pamiętał, który klient ma otwarty dany plik, co ułatwiało restart serwera po awarii, ale wymuszało delegowanie krytycznych funkcji do zewnętrznych, asynchronicznych demonów pomocniczych. Blokowanie plików wymagało protokołu NLM (Network Lock Manager), a powiadamianie o restartach – protokołu NSM (Network Status Monitor realizowanego przez rpc.statd). W przypadku niespójności stanów między tymi demonami dochodziło do zawieszenia operacji plikowych i powstawania osieroconych blokad (stale locks).

W NFSv4 wprowadzono pełną stanowość. Wszystkie operacje związane z cyklem życia pliku (OPEN, CLOSE, LOCK, LOCKU) stały się integralnymi komendami protokołu bazowego. Serwer przydziela każdemu otwartemu plikowi specjalny stanowy identyfikator stateid, a relacja z klientem chroniona jest mechanizmem odnawialnego leasingu czasowego (Lease Period). Jeśli klient ulegnie awarii, serwer po upływie czasu leasingu automatycznie zwalnia wszystkie jego blokady, przywracając pełną spójność danych bez udziału administratora.

Z punktu widzenia inżynierii bezpieczeństwa sieciowego kluczową przewagą NFSv4 jest eliminacja dynamicznych portów. Podczas gdy uruchomienie klienta NFSv3 wymagało otwarcia na zaporze sieciowej portów 111 (TCP/UDP), 2049 (TCP/UDP) oraz dynamicznie losowanych portów dla demona montowania mountd i menedżera blokad lockd (co wymuszało żmudne przypisywanie portów na sztywno w plikach konfiguracyjnych jądra), NFSv4 komunikuje się wyłącznie przez pojedynczy, standardowy port TCP 2049. Ponadto mechanizm COMPOUND RPC pozwala na agregację zapytań w jedną ramkę TCP, co radykalnie obniża narzut opóźnień sieciowych w łączach rozległych.

Wyjaśnienie skrótów i pojęć:
Statefulness – stanowość serwera, czyli pamięć o otwartych plikach, blokadach i sesjach klientów.
NLM / NSM – menedżer blokad sieciowych oraz monitor stanu, demony pomocnicze NFSv3.
stateid / leasing – identyfikator stanu otwarcia oraz odnawialna dzierżawa chroniąca spójność po awarii.
COMPOUND RPC – złożone wywołanie łączące wiele operacji w jednym pakiecie, redukujące opóźnienia.
UID / GID – numeryczne identyfikatory użytkownika i grupy w systemie Unix i Linux.

Przydatne łącza: NFSv3 - RFC 1813; NFSv4 - RFC 7530.

Tradycyjne bezpieczeństwo w systemie NFS (znane jako AUTH_SYS lub AUTH_UNIX) opierało się na bezkrytycznym zaufaniu serwera do informacji przesyłanych przez maszynę kliencką. W każdym pakiecie RPC klient po prostu dołączał swój numeryczny identyfikator UID oraz listę grup GID. Każdy użytkownik posiadający uprawnienia administratora (root) na dowolnej maszynie w sieci mógł bez trudu sfałszować nagłówek pakietu i odczytać lub skasować dowolne pliki z serwera NFS. W otwartych sieciach korporacyjnych stanowiło to krytyczną podatność architektoniczną.

W standardzie NFSv4 zaimplementowano zaawansowany framework kryptograficzny RPCSEC_GSS, bazujący na standardzie Generic Security Services Application Program Interface (GSS-API, RFC 2743). Podstawowym mechanizmem uwierzytelniającym stał się protokół Kerberos v5. Administrator może zdefiniować w pliku /etc/exports oraz poleceniu mount jeden z trzech kryptograficznych trybów pracy parametru sec=: krb5, krb5i lub krb5p.

Tryb sec=krb5 zapewnia bezpieczne, wzajemne potwierdzenie tożsamości pomiędzy węzłami za pośrednictwem zaufanego centrum dystrybucji kluczy (KDC). Tryb sec=krb5i dodaje do każdego pakietu kryptograficzną sumę kontrolną (HMAC), uniemożliwiając napastnikowi modyfikację przesyłanych bloków danych w locie (atak typu Man-in-the-Middle). Z kolei tryb sec=krb5p wprowadza pełne szyfrowanie symetryczne (np. AES-256-CTS-HMAC-SHA1-96) całego ładunku danych (payload). Choć tryb krb5p generuje zauważalny narzut na procesor, jest on bezwzględnie wymagany przy transmisji poufnych baz danych, dokumentacji finansowej lub danych medycznych przez niezaufane segmenty sieci.

Dopełnieniem bezpieczeństwa w NFSv4 są natywne listy kontroli dostępu NFSv4 ACL. W przeciwieństwie do tradycyjnych bitów uprawnień POSIX (rwx), NFSv4 ACL umożliwiają definiowanie precyzyjnych wpisów ACE (Access Control Entries) zawierających kilkanaście niezależnych masek uprawnień (np. READ_DATA, WRITE_ATTRIBUTES, DELETE_CHILD) oraz flag dziedziczenia katalogów, co pozwala na bezszwową translację uprawnień w środowiskach integrujących systemy Linux i Windows.

Wyjaśnienie skrótów i pojęć:
RPCSEC_GSS – warstwa bezpieczeństwa RPC negocjująca mechanizmy GSS-API, głównie Kerberos.
sec=sys / krb5 – tryb jawnych UID oraz tryb uwierzytelniania biletami Kerberos bez szyfrowania.
krb5i / krb5p – tryb z integralnością podpisów HMAC oraz tryb z pełną poufnością szyfrowania.
KDC – centrum dystrybucji kluczy Kerberos, zaufana trzecia strona uwierzytelniania.
NFSv4 ACL – rozbudowane listy dostępu z wpisami ACE i flagami dziedziczenia katalogów.

Przydatne łącza: RPCSEC_GSS - RFC 2203; NFSv4 - RFC 7530.

Wybór pomiędzy wdrożeniem serwera SMB (Samba) a serwera NFS stanowi jedną z kluczowych decyzji architektonicznych podczas projektowania korporacyjnej pamięci masowej. Choć oba protokoły realizują to samo nadrzędne zadanie – udostępniają zdalne zasoby dyskowe przez sieć – różnią się diametralnie filozofią projektową, modelem uprawnień oraz sposobem integracji z systemami operacyjnymi klientów.

W infrastrukturach, w których stacjami końcowymi są komputery z systemem Microsoft Windows, protokół SMBv3 nie ma realnej alternatywy. Zapewnia on bezproblemową integrację z kontrolerami domeny Active Directory, automatyczne mapowanie dysków sieciowych za pośrednictwem zasad grupy (GPO) oraz pełne wsparcie dla zaawansowanych list kontroli dostępu NTFS. Klient systemu Windows posiada wprawdzie opcjonalny moduł Client for NFS, jednak jego konfiguracja jest uciążliwa, wydajność ograniczona, a mapowanie identyfikatorów UID/GID w domenie wymaga dedykowanych schematów w Active Directory.

Z kolei w czystych środowiskach uniksowych i linuksowych – takich jak farmy serwerów WWW, platformy wirtualizacyjne czy klastry obliczeniowe HPC – protokół NFS deklasuje konkurencję. Wynika to z faktu, że NFS jest naturalnym rozszerzeniem lokalnego systemu plików POSIX. Nie wymaga translacji nazw plików (np. wielkości liter Case Sensitivity), bezbłędnie obsługuje dowiązania twarde i symboliczne, a brak konieczności emulowania warstwy semantycznej Windows skutkuje mniejszym zużyciem pamięci RAM i procesora na serwerze. Dodatkowo standard NFSv4.1/4.2 z protokołem pNFS umożliwia równoległe skalowanie odczytów na dziesiątki węzłów dyskowych, co czyni go fundamentem współczesnych architektur Cloud i Kubernetes (Persistent Volumes).

Wyjaśnienie skrótów i pojęć:
Windows-centric – środowisko z przewagą stacji Windows i kontrolerów domeny Active Directory.
Unix-centric – środowisko z przewagą serwerów Linux, farm obliczeniowych i klastrów wirtualizacji.
Mandatory locks – blokady wymuszone SMB, blokujące dostęp mimo prób obejścia przez aplikacje.
Advisory locks – blokady doradcze NFS, respektowane wyłącznie przez współpracujące procesy.
Persistent Volumes – trwałe wolumeny Kubernetes, często realizowane na eksportach NFS.

Przydatne łącza: Samba (dokumentacja); NFSv4 - RFC 7530; Microsoft - protokół SMB.

Wdrażanie serwera NFS w systemie Linux opiera się na wysoce zoptymalizowanej implementacji działającej bezpośrednio w przestrzeni jądra (Kernel-Space). W odróżnieniu od historycznych serwerów działających w przestrzeni użytkownika (User-Space NFS daemon – unfsd), moduł jądra nfsd obsługuje przychodzące żądania odczytu i zapisu bez konieczności kosztownego przełączania kontekstu procesora (Context Switching) i kopiowania buforów pamięci pomiędzy jądrem a aplikacją. Zapewnia to maksymalne wykorzystanie przepustowości podsystemu dyskowego i kontrolerów sieciowych.

W dystrybucjach wywodzących się z Debiana (w tym Ubuntu Server) instalacja serwera sprowadza się do zainstalowania metapakietu nfs-kernel-server. Wraz z nim instalowany jest pakiet nfs-common, zawierający podstawowe narzędzia klienckie i diagnostyczne (m.in. showmount, nfsstat, demona rpc.idmapd i rpc.statd) oraz usługa rpcbind. Po instalacji menedżer systemd automatycznie uruchamia odpowiednie jednostki i rejestruje usługi w systemie.

Kluczowym parametrem wydajnościowym serwera NFS jest liczba wątków roboczych jądra, określana parametrem RPCNFSDCOUNT w pliku /etc/default/nfs-kernel-server (lub w pliku /etc/nfs.conf w nowszych wydaniach systemów). Domyślna wartość wynosząca 8 wątków jest wystarczająca jedynie dla małych instalacji testowych. W środowiskach produkcyjnych, gdzie serwer obsługuje jednoczesne żądania od dziesiątek klientów lub maszyn wirtualnych, liczbę wątków należy zwiększyć do 64, 128 lub nawet 256. Zapobiega to kolejkowaniu żądań I/O w buforze gniazda sieciowego i eliminuje zjawisko drastycznych skoków opóźnień (I/O latency spikes).

Wyjaśnienie skrótów i pojęć:
nfs-kernel-server – metapakiet serwera NFS z jądrowym demonem nfsd w Debian i Ubuntu.
nfs-common – pakiet narzędzi klienckich NFS, w tym showmount, nfsstat i idmapd.
nfsd (jądrowy) – wątki jądra obsługujące żądania NFS bez kopiowania buforów do przestrzeni użytkownika.
systemd – menedżer usług sterujący uruchamianiem i autostartem serwera NFS.
RPCNFSDCOUNT – parametr liczby wątków roboczych nfsd w pliku /etc/default/nfs-kernel-server.

Przydatne łącza: NFSv4 - RFC 7530; Debian - podręczniki (manpages).

Wprowadzenie tekstowego formatu reprezentacji tożsamości użytkowników i grup stanowi jedną z najważniejszych innowacji w protokole NFSv4, opisanym w dokumencie RFC 7530. W architekturze NFSv3 tożsamość była definiowana wyłącznie za pomocą 32-bitowej liczby całkowitej (UID i GID). Wymuszało to bezwzględną, rygorystyczną spójność bazy identyfikatorów w całej sieci: jeśli użytkownik w lokalnym pliku /etc/passwd stacji roboczej posiadał UID 1001, a na serwerze pod tym samym numerem zarejestrowany był inny pracownik, operacje plikowe prowadziły do katastrofalnych pomyłek uprawnień lub całkowitej blokady dostępu.

W NFSv4 wyeliminowano ten problem poprzez wprowadzenie kanonicznej reprezentacji tożsamości w formacie użytkownik@domena_nfs (np. jan@firma.lan). Za proces translacji tych ciągów na lokalne wartości UID/GID odpowiada demon przestrzeni użytkownika rpc.idmapd (oraz współpracujący z nim mechanizm translacji w jądrze oparty na buforze keyring i programie nfsidmap). Gdy klient wysyła żądanie utworzenia pliku, przesyła swoją nazwę domenową; serwer po odebraniu pakietu weryfikuje lokalną bazę kont (np. przez NSS, LDAP lub plik passwd) i przypisuje obiektowi właściwy lokalny UID.

Kluczowym elementem tej układanki jest poprawna konfiguracja pliku /etc/idmapd.conf. W sekcji [General] należy bezwzględnie zdefiniować parametr Domain = twoja_domena.lan. Nazwa ta musi być dokładnie taka sama na serwerze oraz wszystkich podłączonych klientach NFSv4. Najczęstszą awarią zgłaszaną przez administratorów po wdrożeniu NFSv4 jest zjawisko, w którym wszystkie nowo utworzone pliki i katalogi natychmiast otrzymują jako właściciela konto nobody oraz grupę nogroup (w dystrybucjach RHEL/CentOS: nfsnobody). Jest to jednoznaczny objaw niespójności domen w pliku /etc/idmapd.conf – demon idmapd, nie potrafiąc dopasować obcej domeny do domeny lokalnej, bezpiecznie mapuje nieznaną tożsamość na anonimowego użytkownika uniwersalnego.

Wyjaśnienie skrótów i pojęć:
użytkownik@domena – kanoniczny format tożsamości NFSv4, na przykład janmałpaasklab.local.
rpc.idmapd – demon przestrzeni użytkownika realizujący translację nazw na UID i GID.
/etc/idmapd.conf – plik konfiguracyjny z sekcją General i parametrem Domain.
nobody:nogroup – anonimowa tożsamość bezpiecznego mapowania nieznanych użytkowników.
NSS / LDAP – usługa przełącznika nazw oraz katalog LDAP, źródła weryfikacji kont na serwerze.

Przydatne łącza: NFSv4 - RFC 7530; Debian - podręczniki (manpages).

Demon rpc.mountd odgrywa fundamentalną rolę w architekturze protokołu NFSv3. Podczas gdy właściwy demon nfsd odpowiada za operacje wejścia/wyjścia na plikach (odczyt, zapis, sprawdzanie atrybutów), demon mountd pełni funkcję strażnika bramy (Gatekeeper). Obsługuje on odrębny protokół MOUNT (program RPC o numerze 100005, specyfikowany w dokumentach RFC 1813 w ramach architektury ONC RPC). Zadaniem mountd jest odebranie początkowego żądania montowania od klienta, odczytanie konfiguracji z pliku /etc/exports, zweryfikowanie adresu IP klienta i wygenerowanie początkowego uchwytu plikowego.

Pojęcie uchwytu plikowego (File Handle) stanowi kamień węgielny bezpieczeństwa i logiki systemów NFS. Uchwyt to ciąg bajtów (w NFSv3 o maksymalnej długości 64 bajtów), który serwer generuje na podstawie wewnętrznych struktur systemu plików (m.in. numeru i-węzła – inode number, numeru urządzenia oraz unikalnego numeru generacji pliku). Od chwili pomyślnego zamontowania klient nie odwołuje się już do pliku za pomocą ścieżki tekstowej (np. /srv/nfs/dane/plik.txt), lecz przesyła w każdym wywołaniu RPC binarny uchwyt plikowy. Dzięki temu zmiana nazwy katalogu nadrzędnego na serwerze nie przerywa aktywnego transferu realizowanego przez klienta.

Największym wyzwaniem inżynierskim związanym z demonem mountd w sieciach produkcyjnych jest alokacja portów. Domyślnie demon ten podczas startu pobiera wolny port efemeryczny. Aby umożliwić przepuszczenie ruchu przez zaporę sieciową (iptables, nftables, ufw), administrator musi wymusić stały numer portu. W systemach Ubuntu/Debian realizuje się to poprzez dopisanie flagi -p 32767 do zmiennej RPCMOUNTDOPTS w pliku /etc/default/nfs-kernel-server. Warto podkreślić, że w standardzie NFSv4 protokół MOUNT został całkowicie zlikwidowany – klient montuje zasób bezpośrednio za pośrednictwem operacji LOOKUP skierowanej na pojedynczy port TCP 2049.

Wyjaśnienie skrótów i pojęć:
File Handle – binarny uchwyt pliku zwracany przez serwer, używany zamiast ścieżki tekstowej.
inode – i-węzeł systemu plików zawierający metadane i lokalizację bloków danych.
RPCMOUNTDOPTS – zmienna opcji demona mountd w Debian i Ubuntu, miejsce wymuszenia stałego portu.
/etc/nfs.conf – nowoczesny plik konfiguracyjny NFS z sekcją mountd i parametrem port.
LOOKUP – operacja NFSv4 odnajdująca obiekt bezpośrednio na porcie 2049 bez protokołu MOUNT.

Przydatne łącza: NFSv3 - RFC 1813; NFSv4 - RFC 7530.

Pseudo-system plików (ang. pseudo-filesystem) stanowi jedną z najbardziej eleganckich i funkcjonalnych innowacji wprowadzonych w specyfikacji NFSv4 (RFC 7530). W architekturze NFSv3 klient musiał posiadać dokładną wiedzę o strukturze katalogów na serwerze. Jeśli administrator udostępniał pięć różnych partycji, każda z nich musiała zostać jawnie wpisana do pliku /etc/fstab klienta z podaniem jej pełnej ścieżki bezwzględnej (np. serwer:/var/share1, serwer:/opt/share2). Dodatkowo klient nie miał możliwości nawigowania w górę drzewa ponad zamontowany punkt.

W NFSv4 serwer tworzy spójne, wirtualne drzewo przestrzeni nazw, którego wierzchołek definiowany jest w pliku /etc/exports za pomocą specjalnej opcji fsid=0 (lub jej semantycznego synonimu fsid=root). Wszystkie pozostałe eksporty udostępniane w ramach NFSv4 muszą być logicznymi podkatalogami tego korzenia. Klient po nawiązaniu połączenia z pojedynczym portem 2049 TCP montuje bezpośrednio zasób serwer:/. Następnie, korzystając ze standardowych operacji LOOKUP oraz READDIR, może w sposób całkowicie przezroczysty przeglądać całe drzewo dostępnych dla niego zasobów, dokładnie tak, jakby poruszał się po lokalnym dysku twardym.

W praktyce administracyjnej często zachodzi potrzeba udostępnienia katalogów fizycznie zlokalizowanych na różnych wolumenach LVM lub macierzach RAID. W tym celu stosuje się uniksowy mechanizm wiązania katalogów (ang. bind mount). Administrator tworzy katalog bazowy (np. /export z opcją fsid=0), a następnie za pomocą polecenia mount --bind /dane/magazyn /export/magazyn włącza dowolny fragment lokalnego systemu plików do wirtualnego drzewa NFSv4. Wpisy te utrwala się w pliku /etc/fstab serwera z flagą bind, co gwarantuje pełną odporność konfiguracji na restarty systemu operacyjnego.

Wyjaśnienie skrótów i pojęć:
fsid=0 / fsid=root – oznaczenie korzenia pseudo systemu plików w pliku /etc/exports.
Pseudo-Root – wirtualny wierzchołek drzewa eksportów NFSv4 udostępniany klientom.
mount --bind – dowiązanie katalogu do innego punktu drzewa bez kopiowania danych.
READDIR – operacja odczytu zawartości katalogu w protokole NFS.
LVM / RAID – menedżer wolumenów logicznych oraz macierz dyskowa, typowe źródła fizycznych katalogów.

Przydatne łącza: NFSv4 - RFC 7530; Debian - podręczniki (manpages).

Plik /etc/exports jest fundamentalnym elementem konfiguracji każdego serwera Network File System. Określa on precyzyjnie, które lokalne systemy plików lub ich poddrzewa mają zostać udostępnione przez sieć, do jakich adresów IP lub domen ograniczony jest dostęp oraz jakie prawa operacyjne przysługują poszczególnym węzłom. Każda niezakomentowana linia pliku odpowiada jednemu eksportowi i może zawierać definicje uprawnień dla wielu różnych klientów lub podsieci.

Najbardziej znaną, a zarazem najbardziej niebezpieczną pułapką składniową w historii uniksowej administracji jest kwestia spacji pomiędzy nazwą klienta a nawiasem zawierającym listę opcji. Składnia parsera exportfs zakłada, że spacja oddziela definicje kolejnych klientów. Zapis /srv/nfs/dane 192.168.56.101(rw,sync) działa prawidłowo – stacja 101 otrzymuje prawa odczytu i zapisu. Jednak wpisanie spacji: /srv/nfs/dane 192.168.56.101 (rw,sync) zostaje zinterpretowane jako dwa niezależne wpisy: host 192.168.56.101 z domyślnymi uprawnieniami (tylko do odczytu) oraz klient uniwersalny dowolny host na świecie (*) z pełnymi prawami (rw,sync). Taki z pozoru niewinny błąd typograficzny otwiera krytyczną lukę bezpieczeństwa.

Określanie klientów za pomocą adresów IP lub podsieci CIDR jest rozwiązaniem najbardziej niezawodnym i odpornym na awarie infrastruktury pomocniczej. W przypadku stosowania nazw FQDN lub masek wieloznacznych (np. *.firma.lan), serwer NFS przy każdym żądaniu montowania musi wykonać zapytanie zwrotne do systemu DNS (Reverse DNS Lookup), aby zweryfikować, czy adres IP łączącego się klienta odpowiada deklarowanej nazwie domenowej. Jeśli serwer DNS ulegnie awarii lub wystąpią opóźnienia w strefie in-addr.arpa, operacje montowania na klientach zostaną całkowicie zablokowane.

Wyjaśnienie skrótów i pojęć:
/etc/exports – główny plik eksportów NFS, wiersz to katalog, klient i opcje w nawiasach.
etab – plik /var/lib/nfs/etab z rzeczywistą tabelą eksportów interpretowaną przez demony.
rmtab – plik /var/lib/nfs/rmtab z historyczną listą hostów montujących zasoby.
CIDR (pod sieć) – zapis podsieci z prefiksem, na przykład 192.168.56.0/24 dla sieci laboratoryjnej.
FQDN – w pełni kwalifikowana nazwa domenowa hosta, dopuszczalna jako specyfikacja klienta.

Przydatne łącza: NFSv4 - RFC 7530; Debian - podręczniki (manpages).

Dobór parametrów w pliku /etc/exports decyduje o kompromisie pomiędzy integralnością danych, bezpieczeństwem sieciowym a wydajnością podsystemu wejścia/wyjścia serwera NFS. Najważniejszym parametrem pod kątem niezawodności jest dyrektywa określająca tryb synchronizacji danych dyskowych: sync kontra async.

Opcja sync wymusza ścisłą semantykę transakcyjną. Gdy aplikacja na stacji klienckiej wykonuje operację zapisu (wywołanie write() lub fsync()), serwer NFS przesyła pakiet potwierdzenia RPC dopiero w momencie, gdy kontroler dyskowy fizycznie zapisze bloki danych na pamięci trwałej (np. dyskach SAS/SATA/NVMe). Zapewnia to wysoką odporność na nagłą awarię zasilania serwera plików. Z kolei opcja async pozwala serwerowi na natychmiastowe odesłanie potwierdzenia, gdy dane znajdują się jeszcze w ulotnej pamięci podręcznej RAM. Choć drastycznie przyspiesza to operacje I/O, w razie awarii zasilania lub awarii jądra serwera dochodzi do nieodwracalnej utraty danych oraz uszkodzenia struktur logicznych systemu plików (np. ext4 lub XFS).

Kolejną kluczową dyrektywą jest no_subtree_check. Gdy serwer eksportuje podkatalog większego systemu plików (np. /dane/projekty z partycji /dane), domyślna w dawnych wersjach opcja subtree_check zmuszała jądro do każdorazowego sprawdzania, czy odpytywany plik nadal znajduje się w granicach wyeksportowanego poddrzewa. Powodowało to olbrzymi narzut obliczeniowy, a w przypadku zmiany nazwy otwartego pliku lub jego przeniesienia przez inny proces skutkowało generowaniem fałszywych błędów Stale NFS file handle. Współczesne zalecenia inżynierskie jednoznacznie nakazują stosowanie opcji no_subtree_check we wszystkich produkcyjnych konfiguracjach NFS.

Wyjaśnienie skrótów i pojęć:
rw / ro – udostępnienie do odczytu i zapisu albo wyłącznie do odczytu.
sync / async – zapis synchroniczny z potwierdzeniem po dysku albo asynchroniczny z potwierdzeniem po buforze.
no_subtree_check – wyłączenie sprawdzania poddrzewa, zalecane dla wydajności i stabilności eksportów.
all_squash – mapowanie wszystkich użytkowników na konto anonimowe, typowe dla zasobów publicznych.
anonuid / anongid – jawne wskazanie anonimowego UID i GID dla mapowanych tożsamości.

Przydatne łącza: NFSv4 - RFC 7530; Debian - podręczniki (manpages).

Mechanizm spłaszczania uprawnień administratora (ang. root squashing) stanowi najważniejszy i najbardziej elementarny mechanizm obronny w architekturze Network File System. Wynika on bezpośrednio ze specyfiki modelu uwierzytelniania uniksowego. W tradycyjnym protokole NFS klient przesyła w nagłówku zapytania numeryczny identyfikator UID procesu wykonującego operację. Na lokalnej stacji roboczej (np. laptopie pracownika) każdy użytkownik może bez trudu uzyskać uprawnienia roota (UID 0), uruchomić system z dysku USB lub zmodyfikować kod klienta NFS.

Gdyby serwer NFS bezkrytycznie respektował żądania z identyfikatorem UID 0, użytkownik posiadający roota na własnej stacji zyskałby nieograniczone prawo zapisu, odczytu i usuwania wszystkich plików na serwerze, w tym nadpisywania uprawnień innych pracowników. Włączenie mechanizmu root_squash (będącego domyślnym zachowaniem serwera) sprawia, że jądro serwera w chwili odebrania pakietu z UID 0 dokonuje natychmiastowej translacji tej wartości na bezpieczny identyfikator anonimowy (zazwyczaj UID 65534 odpowiadający kontu nobody). W rezultacie zdalny administrator ma na serwerze uprawnienia nie większe niż przypadkowy gość sieciowy.

Zastosowanie opcji no_root_squash jest traktowane przez audytorów bezpieczeństwa jako poważne uchybienie konfiguracyjne. Pozwala ono zdalnemu użytkownikowi na utworzenie w udziale pliku wykonywalnego należącego do roota z ustawionym bitem SUID (SetUID – np. skompilowanej powłoki z prawami chmod 4755 shell). Następnie napastnik, logując się na serwerze jako zwykły użytkownik, może uruchomić ten plik i natychmiast przejąć całkowitą kontrolę nad całą maszyną serwera plików. Opcja no_root_squash może być stosowana wyłącznie w ściśle wydzielonych, dedykowanych sieciach pamięci masowej (Storage SAN/VLAN), np. podczas montowania katalogu głównego dla bezdyskowych terminali sieciowych.

Wyjaśnienie skrótów i pojęć:
UID 0 (root) – identyfikator administratora systemu, w NFS bez ochrony oznaczałby pełną kontrolę nad serwerem.
nobody (65534) – anonimowe konto docelowe mapowania, pozbawione praw do cudzych plików.
no_root_squash – wyłączenie ochrony, dopuszczalne wyłącznie dla zaufanego serwera kopii zapasowych.
SUID (SetUID) – bit wykonywania z uprawnieniami właściciela, groźny przy zdalnym tworzeniu plików roota.
Storage VLAN – wydzielona sieć magazynowa dla ruchu dyskowego, odseparowana od stacji użytkowników.

Przydatne łącza: NFSv4 - RFC 7530; NFSv3 - RFC 1813.

Podstawowym narzędziem administracyjnym służącym do kontrolowania procesu udostępniania zasobów na serwerze NFS jest program exportfs. W odróżnieniu od wielu innych usług sieciowych, serwer NFS po zmodyfikowaniu pliku konfiguracyjnego /etc/exports nie wymaga restartowania całej usługi systemowej (poleceniem systemctl restart nfs-kernel-server). Restart demonów jądra nfsd jest wręcz wysoce niewskazany w środowisku produkcyjnym, gdyż powoduje chwilowe zerwanie aktywnych sesji klienckich i wymusza ponowną renegocjację blokad plikowych.

Wzorcową procedurą aplikowania zmian w konfiguracji eksportów jest wydanie polecenia exportfs -arv. Flaga -a nakazuje przetworzenie wszystkich wpisów z pliku /etc/exports oraz plików z katalogu /etc/exports.d/, flaga -r (re-export) wymusza synchronizację tabeli eksportów w jądrze (usuwając nieaktualne wpisy i dodając nowe), natomiast flaga -v (verbose) wyświetla szczegółowe komunikaty informujące o zaaplikowanych opcjach. Program exportfs parsuje pliki tekstowe i zapisuje skonsolidowany wynik do wewnętrznego pliku bazy danych /var/lib/nfs/etab (Export Table), z którego bezpośrednio korzystają demony rpc.mountd oraz moduł jądra nfsd.

Z punktu widzenia administratora stacji roboczej kluczowym narzędziem diagnostycznym jest polecenie showmount. Wydanie komendy showmount -e adres_serwera wysyła zapytanie RPC do demona mountd na badanym serwerze, prosząc o wylistowanie wszystkich zdefiniowanych udziałów wraz z maskami dozwolonych podsieci. Należy jednak pamiętać o istotnym ograniczeniu inżynierskim: polecenie showmount korzysta z historycznego protokołu MOUNT (port dynamiczny w NFSv3). W nowoczesnych, zabezpieczonych środowiskach opartych wyłącznie na protokole NFSv4, gdzie porty pomocnicze są zablokowane na zaporze ogniowej, showmount zakończy się błędem przekroczenia limitu czasu (RPC: Timed out) pomimo faktu, że właściwy zasób NFSv4 na porcie 2049 działa bez zarzutu.

Wyjaśnienie skrótów i pojęć:
exportfs -arv – przeładowanie wszystkich eksportów z synchronizacją i komunikatami szczegółowymi.
exportfs -v / -u – podgląd aktywnych eksportów oraz natychmiastowe usunięcie wskazanego eksportu.
/var/lib/nfs/etab – rzeczywista tabela eksportów generowana przez exportfs dla demonów.
showmount -e – odpytanie serwera o listę udziałów za pomocą protokołu MOUNT.
RPC Timed out – przekroczenie czasu RPC, typowe przy filtrowaniu portu mountd w NFSv4.

Przydatne łącza: NFSv4 - RFC 7530; Debian - podręczniki (manpages).

Zaprezentowany listing pliku /etc/exports ilustruje wzorcowe, bezpieczne podejście do projektowania przestrzeni eksportów sieciowych w organizacji. Konfiguracja ta realizuje cztery odmienne scenariusze biznesowe, demonstrując precyzyjne łączenie parametrów wydajnościowych i reguł kontroli dostępu.

Wpis pierwszy definiuje korzeń wirtualnego pseudo-systemu plików NFSv4 (/srv/nfs) za pomocą opcji fsid=0 (dopuszczalny jest też zapis fsid=root). Zezwala on maszynom z podsieci laboratoryjnej 192.168.56.0/24 na trawersowanie struktury katalogów w trybie tylko do odczytu (ro). Dzięki temu klienci NFSv4 mogą zamontować zasób serwer:/ i automatycznie odkryć wszystkie podległe punkty montowania bez konieczności rekonfigurowania lokalnych tabel.

Wpis drugi definiuje zasób ogólnodostępny /srv/nfs/public. Zastosowanie opcji all_squash gwarantuje, że każda operacja plikowa – niezależnie od tego, jaki użytkownik ją zainicjuje – zostanie wykonana w kontekście bezpiecznego konta anonimowego (nobody). Wpis trzeci udostępnia przestrzeń roboczą projektów wyłącznie dla jednej, zaufanej stacji roboczej (192.168.56.101) z prawami pełnego odczytu i zapisu (rw). Zastosowanie opcji root_squash zabezpiecza serwer przed eskalacją uprawnień ze strony lokalnego administratora stacji.

Ostatni wpis dotyczy dedykowanego zasobu archiwalnego /srv/nfs/backup. W tym unikalnym przypadku administrator świadomie zezwolił na wyłączenie mechanizmu ochronnego (no_root_squash), ograniczając jednak dostęp wyłącznie do jednego adresu IP serwera kopii zapasowych (192.168.56.200). Jest to niezbędne, aby demon backupu mógł odtworzyć pliki systemowe z zachowaniem ich oryginalnych, uniksowych właścicieli (UID 0 dla binariów systemowych) bez błędu braku uprawnień.

Wyjaśnienie skrótów i pojęć:
fsid=0 – wyróżnik korzenia NFSv4 umożliwiający montowanie serwera przez sam ukośnik.
all_squash – pełne spłaszczenie wszystkich tożsamości na konto anonimowe w zasobie publicznym.
root_squash – spłaszczenie zdalnego roota, standardowa ochrona zasobu projektowego.
no_root_squash – świadome wyłączenie ochrony wyłącznie dla serwera kopii odtwarzającego własność.
Zasada minimalnych uprawnień – udostępnianie wyłącznie wymaganego katalogu wymaganym hostom i z wymaganym trybem.

Przydatne łącza: NFSv4 - RFC 7530; Debian - podręczniki (manpages).

Proces montowania sieciowego systemu plików NFS na stacji roboczej lub serwerze aplikacyjnym wymaga precyzyjnego doboru parametrów jądra przekazywanych w przełączniku -o polecenia mount. Niewłaściwy dobór flag może prowadzić do drastycznego spadku przepustowości transmisji lub – w skrajnych przypadkach – do uszkodzenia struktur zapisywanych plików w przypadku chwilowej niestabilności sieci LAN.

Jedną z najważniejszych decyzji inżynierskich jest wybór pomiędzy opcją hard a soft. W trybie hard (stanowiącym domyślny standard jądra Linux), gdy serwer plików ulegnie awarii lub zrestartuje się, procesy klienckie wykonujące operacje dyskowe zostają bezpiecznie zawieszone w stanie oczekiwania na zasób (Uninterruptible Sleep – stan D w podglądzie procesów ps/top). Klient ponawia próby transmisji w nieskończoność. Gdy serwer powróci do pracy, transfer jest bezbłędnie wznawiany bez utraty spójności danych. Z kolei w trybie soft klient po określonej liczbie nieudanych prób (sterowanej parametrami timeo oraz retrans) poddaje się i zwraca do aplikacji błąd wejścia/wyjścia (EIO). Dla baz danych (np. PostgreSQL, MySQL) lub wirtualizatorów oznacza to natychmiastowe uszkodzenie tabel i awarię usług. Dlatego tryb soft jest dopuszczalny wyłącznie dla niekrytycznych danych statycznych (np. repozytoriów obrazów ISO).

Kolejnym aspektem jest dostrojenie buforów odczytu i zapisu: rsize oraz wsize. W architekturze NFSv4 negocjacja tych wartości zachodzi automatycznie, jednak w sieciach o wysokiej przepustowości (10 GbE, 40 GbE) ręczne wymuszenie rozmiaru 1048576 bajtów (1 MB) pozwala na przesyłanie potężnych bloków danych w pojedynczych seriach TCP, minimalizując narzut generowania nagłówków pakietów przez procesor. Dodatkowo ze względów bezpieczeństwa każdy udział montowany dla zwykłych użytkowników powinien bezwzględnie posiadać flagi nosuid oraz nodev, co uniemożliwia wykonanie ataku eskalacji uprawnień za pomocą podrzuconych plików binarnych.

Wyjaśnienie skrótów i pojęć:
hard / soft – zawieszanie procesów do powrotu serwera albo zwracanie błędu po limitowanych próbach.
retrans / timeo – liczba ponowień oraz czas oczekiwania sterujące zachowaniem klienta w trybie miękkim.
rsize / wsize – rozmiary buforów odczytu i zapisu, optymalne na poziomie megabajta dla sieci szybkich.
nosuid / nodev / noexec – blokada bitu SUID, plików urządzeń i wykonywania binariów z udziału.
D-state – stan nieprzerwalnego oczekiwania procesu na zasób dyskowy w trybie twardym.

Przydatne łącza: NFSv4 - RFC 7530; Debian - podręczniki (manpages).

Zapewnienie stabilnego i bezawaryjnego dostępu do zasobów sieciowych po restarcie systemu operacyjnego stacji roboczej lub serwera wymaga starannego zaplanowania mechanizmu montowania. Klasycznym podejściem jest umieszczenie wpisu w pliku /etc/fstab. Jednak w przypadku zasobów sieciowych tradycyjna składnia okazuje się niewystarczająca i może doprowadzić do paraliżu procedury startowej maszyny.

Krytycznym elementem wpisu w /etc/fstab jest parametr _netdev. Standardowe systemy plików (ext4, XFS) montowane są na wczesnym etapie startu systemu, zanim nastąpi konfiguracja adresów IP i uruchomienie menedżera sieci. Flaga _netdev stanowi jawną instrukcję dla generatorów jednostek systemd (systemd-fstab-generator), nakazującą odłożenie montowania tego zasobu do momentu przejścia do stanu network-online.target. Dodatkowo parametr nofail zabezpiecza stację roboczą: jeśli serwer plików jest wyłączony, system kontynuuje procedurę uruchamiania, zamiast zatrzymywać się w konsoli awaryjnej (Emergency Mode).

W środowiskach wieloserwerowych znacznie bardziej eleganckim i niezawodnym standardem inżynierskim jest wdrożenie usługi autofs. W architekturze tej punkty montowania nie są utrzymywane na stałe. Demon automount nasłuchuje na poziomie jądra na wywołania w wyznaczonym katalogu (np. /mnt/nfs/). Gdy użytkownik lub proces wyda polecenie wejścia do katalogu (np. cd /mnt/nfs/public), demon w ułamku sekundy montuje odpowiedni zasób NFS w tle. Jeśli przez określony czas (domyślnie 300 sekund) żaden proces nie odwołuje się do danych, zasób zostaje automatycznie odmontowany. Całkowicie eliminuje to problem zawieszania się stacji roboczych podczas nagłych awarii serwera plików oraz drastycznie redukuje liczbę otwartych sesji TCP w sieci.

Wyjaśnienie skrótów i pojęć:
/etc/fstab – statyczna tabela systemów plików montowanych podczas startu systemu.
_netdev / nofail – flaga zależności od sieci oraz flaga kontynuacji startu mimo błędu montowania.
x-systemd.automount – jednostka systemd montująca zasób dopiero przy pierwszym odwołaniu.
autofs / automount – demon automatycznego montowania i odmontowywania po bezczynności.
network-online.target – stan systemd oznaczający gotowość stosu sieciowego do montowań sieciowych.

Przydatne łącza: NFSv4 - RFC 7530; Debian - podręczniki (manpages).

Wraz z nadejściem ery przetwarzania wielkich zbiorów danych (Big Data), uczenia maszynowego oraz klastrów obliczeniowych wysokiej wydajności (High Performance Computing – HPC), tradycyjna architektura serwerów plików napotkała nieprzekraczalną barierę skalowalności. W klasycznym modelu NFS pojedynczy serwer plików musiał jednocześnie przetwarzać żądania metadanych (uprawnienia, atrybuty, blokady) oraz przesyłać gigabajty danych binarnych przez swoje interfejsy sieciowe, stając się wąskim gardłem całej infrastruktury.

Odpowiedzią IETF na to wyzwanie stała się specyfikacja pNFS (Parallel NFS), stanowiąca kluczowy element standardu NFSv4.1 (RFC 5661, skonsolidowanego w RFC 8881). Architektura pNFS dokonuje radykalnego rozdziału pomiędzy ścieżką metadanych a ścieżką danych operacyjnych. W systemie pNFS występuje pojedynczy Serwer Metadanych (Metadata Server – MDS) oraz dowolna liczba Serwerów Danych (Data Servers – DS). Gdy klient chce odczytać lub zmodyfikować potężny plik (np. obraz dysku wirtualnego o wielkości 1 TB), wysyła zapytanie LAYOUTGET do serwera MDS.

Serwer MDS weryfikuje uprawnienia użytkownika i zwraca klientowi tzw. układ (Layout) – mapę wskazującą, na których fizycznych serwerach danych DS znajdują się poszczególne fragmenty (paski – stripes) poszukiwanego pliku. Posiadając tę wiedzę, klient pNFS zestawia niezależne, w pełni równoległe połączenia sieciowe do dziesiątek serwerów danych jednocześnie, pobierając lub zapisując dane z sumaryczną przepustowością sięgającą setek gigabitów na sekundę z pominięciem serwera MDS. Mechanizm ten eliminuje problem pojedynczego punktu zatoru i pozwala na niemal liniowe skalowanie wydajności pamięci masowej w miarę dodawania kolejnych węzłów dyskowych.

Wyjaśnienie skrótów i pojęć:
MDS (Metadata Server) – serwer metadanych obsługujący otwarcia, uprawnienia i strukturę katalogów.
DS (Data Server) – serwer danych przechowujący właściwe bloki plików i obsługujący transfer.
Layout / LAYOUTGET – mapa rozmieszczenia pasków pliku oraz operacja jej pobierania z serwera metadanych.
File / Block / Object Layout – układy plikowy, blokowy SAN oraz obiektowy dla magazynów chmurowych.
HPC / Big Data – klastry wysokiej wydajności oraz wielkie zbiory danych, główne zastosowania pNFS.

Przydatne łącza: NFSv4.1 - RFC 8881; NFSv4 - RFC 7530; NFSv4.2 - RFC 7862.

Niniejszy moduł laboratoryjny został zaprojektowany z myślą o praktycznym utrwaleniu wiedzy inżynierskiej zdobytej w części teoretycznej wykładu. W środowisku wirtualnym odwzorowano typową topologię sieci przedsiębiorstwa, w której dedykowany serwer pamięci masowej (Storage Server) udostępnia przestrzeń dyskową dla stacji roboczych i serwerów aplikacyjnych za pośrednictwem dwóch równolegle działających protokołów: SMB oraz NFS.

Środowisko ćwiczeniowe opiera się na dwóch instancjach systemu Ubuntu Server 22.04 LTS połączonych odizolowaną podsiecią prywatną 192.168.56.0/24. Węzeł serwerowy (192.168.56.100) pełni rolę centralnego magazynu danych, na którym uczestnicy skonfigurują usługę Samba z dwoma odrębnymi profilami dostępu (udział publiczny tylko do odczytu oraz udział prywatny z autoryzacją użytkowników) oraz jądrowy serwer NFS z włączonymi mechanizmami kontroli tożsamości.

Węzeł kliencki (192.168.56.101) posłuży do przeprowadzania testów penetracyjnych i funkcjonalnych. Uczestnicy będą mieli okazję zweryfikować zachowanie protokołów w praktyce: przetestować odmowę dostępu przy błędnym haśle SMB, zbadać działanie maski uprawnień plików, sprawdzić reakcję systemu na próbę zapisu do eksportu tylko do odczytu w NFS oraz na własne oczy zaobserwować działanie mechanizmu root_squash, który uniemożliwi zdalnemu rootowi przejęcie kontroli nad plikami serwera.

Wyjaśnienie skrótów i pojęć:
SRV-STORAGE – wirtualny węzeł serwerowy udostępniający udziały SMB i eksporty NFS.
CLI-CLIENT – wirtualny węzeł kliencki do testów dostępu, montowania i uprawnień.
cifs-utils – pakiet narzędzi do montowania udziałów SMB w systemie Linux.
Host-Only / bridge – izolowana sieć hosta albo most do sieci fizycznej dla maszyn wirtualnych.
Ubuntu 22.04 LTS – wydanie Linux ze wsparciem długoterminowym, baza ćwiczenia laboratoryjnego.

Przydatne łącza: Samba (dokumentacja); NFSv4 - RFC 7530.

Pierwsze ćwiczenie praktyczne polega na wdrożeniu najprostszego, a zarazem powszechnie stosowanego typu udziału sieciowego – zasobu publicznego przeznaczonego wyłącznie do odczytu (np. do dystrybucji sterowników, wzorów dokumentów czy instalatorów oprogramowania w sieci firmowej). Konfiguracja ta wymaga zrównoważenia wygody użytkowników (brak konieczności wprowadzania haseł) z bezpieczeństwem danych (całkowita blokada możliwości modyfikacji lub skasowania zawartości).

Kluczowym elementem wdrożenia, o którym często zapominają początkujący administratorzy, jest prawidłowe przygotowanie uprawnień w lokalnym systemie plików serwera przed dodaniem wpisu do konfiguracji Samby. Katalog /srv/samba/public otrzymuje jako właściciela konto nobody:nogroup oraz uprawnienia POSIX 0755 (drwxr-xr-x). Oznacza to, że proces Samby reprezentujący anonimowego gościa będzie mógł swobodnie odczytywać pliki i przeglądać katalogi, ale nie uzyska prawa zapisu na poziomie jądra systemu operacyjnego.

W pliku /etc/samba/smb.conf deklarujemy sekcję [Publiczny]. Parametr guest ok = yes informuje demona smbd, że klienci łączący się bez poświadczeń lub z pustym hasłem mają zostać automatycznie zmapowani na konto gościa (zdefiniowane w sekcji globalnej dyrektywą guest account = nobody). Z kolei dyrektywa read only = yes stanowi drugą, niezależną linię obrony w warstwie protokołu SMB – nawet gdyby uprawnienia w systemie plików pozwalały na zapis, serwer SMB odrzuci wszelkie żądania SMB2_WRITE lub SMB2_CREATE.

Po zakończeniu edycji konfiguracji bezwzględnie weryfikujemy jej poprawność za pomocą narzędzia testparm -s. Jeśli polecenie nie wykaże błędów składniowych ani ostrzeżeń, przeładowujemy demona poleceniem systemctl reload smbd. Użycie akcji reload zamiast restart jest wysoce zalecane, ponieważ odczytuje nowy plik konfiguracyjny bez zrywania aktywnych sesji innych użytkowników podłączonych do serwera.

Wyjaśnienie skrótów i pojęć:
guest ok = yes – zezwolenie na mapowanie sesji anonimowych na konto gościa.
read only = yes – blokada operacji zapisu i tworzenia na poziomie protokołu SMB.
nobody:nogroup – anonimowy właściciel katalogu publicznego w systemie plików.
0755 (drwxr-xr-x) – uprawnienia POSIX z zapisem właściciela oraz odczytem dla pozostałych.
reload smbd – przeładowanie konfiguracji bez zrywania aktywnych sesji użytkowników.

Przydatne łącza: smb.conf (Samba Wiki); Samba (dokumentacja).

Drugie ćwiczenie laboratoryjne obejmuje konfigurację zaawansowanego udziału poufnego, wymagającego ścisłej kontroli tożsamości oraz uprawnień do zapisu dla wyznaczonej grupy pracowniczej. W tym scenariuszu demonstrujemy harmonijną współpracę pomiędzy uprawnieniami na poziomie usługi Samba a uprawnieniami lokalnego systemu plików Linux.

Kluczowym elementem przygotowania środowiska jest utworzenie dedykowanej grupy kadry oraz konta użytkownika jan. Ponieważ konto to ma służyć wyłącznie do sieciowego dostępu do plików przez protokół SMB, a nie do bezpośredniego logowania interaktywnego na serwer przez protokół SSH, tworzymy je z przełącznikiem -s /usr/sbin/nologin oraz -M (bez tworzenia domyślnego katalogu domowego). Następnie dodajemy konto do bazy Samby za pomocą polecenia smbpasswd -a jan, definiując bezpieczne poświadczenia sieciowe.

Niezwykle istotnym zabiegiem inżynierskim jest nadanie katalogowi /srv/samba/private praw dostępu 2770 (drwxrws---). Wartość 2 na pierwszej pozycji oznacza aktywację specjalnego bitu SGID (Set Group ID) na katalogu. W systemach uniksowych bit SGID na folderze gwarantuje, że każdy nowy plik lub podkatalog utworzony w tym miejscu automatycznie odziedziczy grupę nadrzędną (tutaj: kadry), niezależnie od tego, jaka jest domyślna grupa główna użytkownika wykonującego operację zapisu. W połączeniu z parametrami create mask = 0660 i directory mask = 0770 w pliku smb.conf zapobiega to powstawaniu plików zablokowanych dla innych członków zespołu.

W definicji udziału parametr valid users = @kadry gwarantuje, że serwer odrzuci każdego użytkownika, który nie jest członkiem grupy kadry (prefiks @ oznacza grupę systemową). Dyrektywa read only = no zezwala na operacje modyfikacji, a guest ok = no bezwzględnie blokuje wszelkie próby połączeń anonimowych.

Wyjaśnienie skrótów i pojęć:
valid users = @grupa – ograniczenie sesji do członków wskazanej grupy systemowej lub domenowej.
guest ok = no – blokada dostępu anonimowego, wymóg podania loginu i hasła.
0660 / 0770 – maski POSIX z pełnym dostępem właściciela i grupy przy braku praw innych.
smbpasswd -a – dodanie użytkownika i ustawienie hasła SMB w bazie passdb.
chown / chmod – zmiana właściciela oraz trybu dostępu do katalogu udziału w systemie plików.

Przydatne łącza: smb.conf (Samba Wiki); Samba (dokumentacja).

Rzetelna procedura weryfikacyjna serwera plików po stronie stacji klienckich powinna obejmować zarówno testy pozytywne (sprawdzające prawidłowe działanie funkcji przy poprawnych danych uwierzytelniających), jak i testy negatywne (weryfikujące skuteczne blokowanie prób nieautoryzowanego dostępu).

Podstawowym narzędziem audytowym dla inżyniera sieciowego jest program smbclient. W pierwszym teście wysyłamy zapytanie o listę dostępnych zasobów za pomocą opcji -L z przełącznikiem -U%, oznaczającym połączenie z pustą nazwą użytkownika i hasłem (sesja gościa/anonimowa). Następnie łączymy się z udziałem publicznym i weryfikujemy możliwość pobrania pliku testowego. Kluczowym krokiem jest próba nawiązania sesji anonimowej z zasobem prywatnym – serwer musi bezwzględnie zwrócić kod błędu NT_STATUS_ACCESS_DENIED lub NT_STATUS_LOGON_FAILURE. Dopiero podanie prawidłowego konta -U jan wraz z hasłem powinno otworzyć interaktywną powłokę SMB.

W systemach Linux do stałego lub doraźnego montowania udziałów SMB służy sterownik jądra cifs (zawarty w pakiecie cifs-utils). Polecenie mount -t cifs wymaga podania parametrów uid oraz gid – definiują one, któremu lokalnemu użytkownikowi na stacji roboczej jądro przypisze prawa własności do zamontowanych plików, co jest niezbędne dla poprawnego działania programów graficznych i menedżerów plików (np. GNOME Files / Nautilus).

W środowiskach Windows weryfikacja polega na zamontowaniu dysku sieciowego za pomocą polecenia net use. Poprawne zamontowanie litery dysku (np. Z:) potwierdza pełną zgodność wdrożonego serwera Samba ze stosem sieciowym Microsoft Windows oraz poprawność działania negocjacji dialektów i cyfrowego podpisywania pakietów SMB.

Wyjaśnienie skrótów i pojęć:
smbclient -L – listowanie udziałów serwera SMB bez montowania systemu plików.
mount -t cifs – montowanie udziału SMB w drzewie Linux z opcjami uwierzytelniania.
credentials (0600) – plik poświadczeń z loginem i hasłem, dostępny wyłącznie dla właściciela.
UNC (ścieżka) – uniwersalna konwencja nazewnictwa, na przykład dwa ukośniki, serwer, ukośnik, udział.
net use – polecenie Windows mapujące udział na literę dysku z trwałym połączeniem.

Przydatne łącza: Samba (dokumentacja); Microsoft - protokół SMB (MS-SMB2).

Druga część laboratorium skupia się na konfiguracji nowoczesnego serwera Network File System z wykorzystaniem zaleceń standardu NFSv4. Po zainstalowaniu pakietu nfs-kernel-server jądro systemu Linux rejestruje niezbędne moduły oraz uruchamia wątki demona nfsd. Naszym zadaniem jest zbudowanie przejrzystej, bezpiecznej hierarchii eksportów w oparciu o koncepcję pseudo-systemu plików.

W strukturze katalogów tworzymy nadrzędny folder /srv/nfs, który w pliku /etc/exports oznaczamy kluczową opcją fsid=0 (co definiuje go jako korzeń wirtualnego drzewa NFSv4 dla łączących się klientów). Wewnątrz tego katalogu tworzymy dwa odrębne zasoby: /srv/nfs/public (przeznaczony wyłącznie do bezpiecznego odczytu dla całej podsieci) oraz /srv/nfs/projects (udostępniony do odczytu i modyfikacji z aktywnym zabezpieczeniem root_squash).

Podczas edycji pliku /etc/exports szczególną uwagę zwracamy na precyzję składni – brak jakichkolwiek spacji pomiędzy adresem podsieci 192.168.56.0/24 a otwierającym nawiasem opcji. Po zapisaniu pliku wydajemy polecenie exportfs -arv. Narzędzie to wczytuje nową konfigurację i natychmiast synchronizuje tabele eksportów w pamięci jądra, wyświetlając na ekranie podsumowanie zastosowanych flag.

Końcowym etapem weryfikacji na serwerze jest zbadanie zawartości systemowego pliku stanu /var/lib/nfs/etab. W odróżnieniu od pliku /etc/exports, plik etab zawiera pełną, skonsolidowaną postać konfiguracji ze wszystkimi domyślnymi parametrami przypisanymi automatycznie przez jądro (takimi jak anonuid=65534, anongid=65534, secure czy wdelay). Stanowi to nieocenione źródło wiedzy podczas precyzyjnego audytu stanu bezpieczeństwa serwera.

Wyjaśnienie skrótów i pojęć:
fsid=0 – wyróżnik korzenia NFSv4 montowanego samym ukośnikiem serwera.
ro / rw – tryb tylko do odczytu dla zasobu publicznego oraz tryb zapisu dla zasobu projektowego.
exportfs -arv – synchronizacja pliku exports z jądrem bez restartu usługi.
POSIX (właściciel) – właściciel i grupa pliku decydujące o rzeczywistym dostępie po stronie serwera.
Podsieć 192.168.56.0/24 – laboratoryjna sieć ćwiczeniowa łącząca serwer i klienta.

Przydatne łącza: NFSv4 - RFC 7530; Debian - podręczniki (manpages).

Prezentowane ćwiczenie stanowi kulminacyjny punkt weryfikacji mechanizmów bezpieczeństwa systemu NFS. Po zamontowaniu obu eksportów na stacji klienckiej przystępujemy do przeprowadzenia kontrolowanych testów mających na celu empiryczne potwierdzenie założeń architektonicznych protokołu.

W pierwszym teście badamy zachowanie zasobu publicznego. Choć uprawnienia w systemie plików serwera mogłyby zezwalać na modyfikację, sterownik NFS klienta po otrzymaniu atrybutów ro natychmiast blokuje wszelkie próby otwarcia deskryptora w trybie zapisu (flagami O_WRONLY lub O_RDWR). Wywołanie polecenia touch natychmiast kończy się uniksowym kodem błędu EROFS (Read-only file system), gwarantując pełną nienaruszalność materiałów informacyjnych.

Drugi test demonstruje fundamentalne zabezpieczenie root_squash. Na stacji roboczej logujemy się na konto lokalnego administratora (root, UID 0) i tworzymy plik w udziale projektowym /mnt/nfs_proj/root_test.txt. Gdyby serwer pracował z niebezpieczną opcją no_root_squash, nowo utworzony plik otrzymałby właściciela root:root (UID 0:0). Jednak dzięki aktywnej ochronie root_squash jądro serwera w ułamku sekundy przetłumaczyło przychodzący identyfikator UID 0 na identyfikator konta anonimowego.

Wykonanie polecenia ls -l na serwerze i kliencie jednoznacznie wykazuje, że właścicielem pliku jest konto nobody (oraz grupa nogroup). Oznacza to, że użytkownik, mimo posiadania pełnych praw roota na stacji roboczej, na serwerze sieciowym nie ma możliwości modyfikacji plików systemowych, instalowania oprogramowania ze znacznikami SUID ani ingerowania w dane innych użytkowników. Stanowi to namacalny dowód skuteczności polityki minimalnych uprawnień w sieciach uniksowych.

Wyjaśnienie skrótów i pojęć:
mount -t nfs – montowanie eksportu NFS z wyborem wersji protokołu opcją vers.
root_squash (test) – oczekiwana odmowa zapisu dla zdalnego administratora po mapowaniu na nobody.
ls -n / stat – narzędzia pokazujące numeryczne UID i GID właścicieli plików.
SUID (test) – próba utworzenia pliku z bitem SetUID w celu weryfikacji braku eskalacji.
Permission denied – odmowa dostępu potwierdzająca poprawne działanie mechanizmu ochronnego.

Przydatne łącza: NFSv4 - RFC 7530; Debian - podręczniki (manpages).

Problemy z mapowaniem tożsamości użytkowników i grup stanowią zdecydowanie najczęstszą kategorię awarii w sieciowych systemach plików NFS. Objawiają się one zazwyczaj niespodziewaną odmową dostępu do katalogów (błędy Permission denied) pomimo z pozoru prawidłowych uprawnień lub pojawieniem się tajemniczych wpisów nobody:nogroup w listingach katalogów.

W przypadku protokołu NFSv4 pojawienie się tożsamości nobody zwykle wskazuje na błąd konfiguracji demona translacji nazw. Protokół NFSv4 przesyła nazwę użytkownika w formacie tekstowym login@domena_nfs. Gdy demon rpc.idmapd na maszynie docelowej odbierze pakiet, sprawdza wartość parametru Domain w sekcji [General] pliku /etc/idmapd.conf. Jeśli domena w pakiecie różni się choćby o jeden znak od domeny lokalnej (np. Domain = asklab.local na serwerze i domyślne Domain = localdomain na kliencie), mechanizm bezpieczeństwa uniemożliwia przypisanie praw lokalnych i automatycznie zastępuje tożsamość bezpiecznym kontem anonimowym nobody. Po ujednoliceniu konfiguracji konieczne jest opróżnienie bufora jądra za pomocą polecenia nfsidmap -c.

Z kolei w protokole NFSv3 źródłem problemu jest bezwzględne poleganie na numerycznych identyfikatorach UID i GID. Jeśli administratorzy zarządzają kontami ręcznie, bardzo łatwo doprowadzić do sytuacji, w której pracownik dodany do systemu na stacji roboczej otrzyma UID 1002, a na serwerze plików pod numerem 1002 zarejestrowana jest zupełnie inna osoba lub usługa systemowa. Jedynym trwałym rozwiązaniem inżynierskim tego problemu w sieciach korporacyjnych jest wdrożenie scentralizowanej bazy tożsamości opartej na protokole LDAP (np. FreeIPA lub Active Directory) wraz z integracją przez podsystem SSSD (System Security Services Daemon).

Wyjaśnienie skrótów i pojęć:
UID / GID – numeryczne identyfikatory użytkownika i grupy, krytyczne dla własności plików NFS.
idmapd.conf (Domain) – plik z domeną NFS, wymagający identycznej wartości na serwerze i klientach.
nobody:nogroup – objaw nieudanego mapowania, bezpieczne przypisanie nieznanej tożsamości.
LDAP / NSS – centralny katalog kont oraz przełącznik usług nazw weryfikujący tożsamości.
getent / id – polecenia sprawdzające rozpoznawanie kont i przynależność do grup.

Przydatne łącza: NFSv4 - RFC 7530; Debian - podręczniki (manpages).

Błędnie skonfigurowana zapora sieciowa (firewall) na serwerze plików lub urządzeniach pośredniczących w sieci LAN stanowi jedną z najczęstszych przyczyn pozornych awarii usług dyskowych. Objawia się ona zawieszaniem poleceń montowania, długimi czasami oczekiwania na odpowiedź (timeouts) lub komunikatami No route to host oraz Connection refused.

W przypadku protokołu SMB zarządzanie regułami zapory sieciowej jest proste i przejrzyste. W nowoczesnych sieciach wystarczy otworzyć wyłącznie pojedynczy port TCP 445 dla zaufanych podsieci roboczych. Porty powiązane z warstwą NetBIOS over TCP/IP (TCP 139 oraz UDP 137 i 138) mogą i powinny pozostać zablokowane, chyba że w sieci funkcjonują historyczne aplikacje wymagające rozgłoszeniowej rezolucji nazw NBNS.

Prawdziwym wyzwaniem dla administratorów bezpieczeństwa jest natomiast protokół NFSv3. Ze względu na swoją architekturę opartą na dynamicznych portach ONC RPC, uruchomienie serwera za zaporą sieciową wymagało zdefiniowania stałych portów dla wszystkich demonów pomocniczych w plikach konfiguracyjnych /etc/default/nfs-kernel-server oraz parametrach modułów jądra w /etc/modprobe.d/. Dopiero po zablokowaniu portów na sztywno możliwe było utworzenie reguł w iptables/nftables dla portów rpcbind (111), nfsd (2049), mountd (np. 32767), statd (np. 32768) oraz nlockmgr (np. 32769).

Zaprojektowany w XXI wieku protokół NFSv4 całkowicie wyeliminował tę złożoność. Klient NFSv4 kontaktuje się z serwerem wyłącznie za pośrednictwem jednego, dobrze znanego portu TCP 2049. Zapora sieciowa serwera wymaga zdefiniowania tylko jednej prostej reguły zezwalającej na ruch z autoryzowanej podsieci CIDR, co drastycznie redukuje powierzchnię ataku i upraszcza audyt bezpieczeństwa teleinformatycznego.

Wyjaśnienie skrótów i pojęć:
TCP 445 / 2049 – porty usługowe SMB oraz NFSv4, jedyne wymagane w nowoczesnych wdrożeniach.
ufw / nftables – nakładka zarządzania zaporą oraz natywny framework filtrowania jądra Linux.
Default deny – domyślna polityka odrzucania ruchu niepasującego do jawnych reguł zezwalających.
VLAN (segmentacja) – podział sieci na segmenty serwerowy, kliencki i zarządzania dla ograniczenia zasięgu ataków.
ss -tulpn – weryfikacja nasłuchu usług przed otwarciem portów w zaporze.

Przydatne łącza: IANA - numery portów; Netfilter (dokumentacja).

Diagnostyka problemów z serwerem Samba wymaga od administratora metodycznego rozróżniania warstw, na których może dojść do wystąpienia błędu. Trzy główne obszary awarii to: błędy parsowania pliku konfiguracyjnego, niepowodzenia procedury uwierzytelniania oraz konflikty uprawnień na styku protokołu SMB i lokalnego systemu plików POSIX.

Błędy składniowe w pliku smb.conf są najprostszą do usunięcia, lecz niezwykle powszechną przyczyną przestojów. Wprowadzenie nieobsługiwanego parametru lub literówki w nazwie dyrektywy może spowodować odrzucenie całej konfiguracji przez demona smbd. Złotą zasadą inżynierską jest każdorazowe wywołanie polecenia testparm przed zrestartowaniem lub przeładowaniem usługi. Program ten w czytelny sposób wskaże numer linii zawierającej błąd oraz ostrzeże przed potencjalnymi konfliktami logicznymi.

Błąd NT_STATUS_LOGON_FAILURE pojawia się w sytuacji, gdy serwer nie jest w stanie zweryfikować tożsamości klienta. W środowiskach autonomicznych przyczyną jest zazwyczaj pominięcie etapu synchronizacji haseł – użytkownik istnieje w systemie Linux (plik /etc/passwd), lecz administrator zapomniał dodać go do bazy haseł SMB poleceniem smbpasswd -a. Pomocnym narzędziem inspekcyjnym jest polecenie pdbedit -L -v, które raportuje stan konta, w tym flagę Account Flags: [U ] informującą, czy konto jest aktywne, czy zablokowane.

Z kolei błąd NT_STATUS_ACCESS_DENIED występujący podczas próby utworzenia nowego pliku jest klasycznym objawem konfliktu uprawnień dwupoziomowych. Nawet jeśli w pliku smb.conf ustawiono parametr read only = no oraz dopisano użytkownika do valid users, Samba nie będzie mogła zapisać pliku, jeżeli konto procesowe nie posiada prawa zapisu (bitu w) w lokalnym systemie plików serwera. Administrator musi zweryfikować uprawnienia katalogu poleceniem ls -ld i upewnić się, że tożsamość, z którą działa proces Samby, posiada odpowiednie prawa POSIX lub wpis w liście kontroli dostępu ACL.

Wyjaśnienie skrótów i pojęć:
systemctl status smbd – sprawdzenie działania demona oraz ostatnich zdarzeń jednostki systemd.
testparm – wykluczenie literówek i przestarzałych dyrektyw przed analizą sieci.
NT_STATUS_LOGON_FAILURE – niepowodzenie logowania z powodu hasła, konta albo blokady.
NT_STATUS_BAD_NETWORK_NAME – błędna nazwa udziału albo literówka w ścieżce UNC.
Uprawnienia POSIX – ostateczny filtr dostępu w systemie plików serwera przy poprawnej sesji SMB.

Przydatne łącza: Samba (dokumentacja); smb.conf (Samba Wiki).

Diagnostyka incydentów w sieciowych systemach plików NFS wymaga dogłębnej znajomości protokołów warstwy sesji i prezentacji oraz interakcji jądra z pamięcią podręczną VFS. Najczęstsze problemy dotyczą procesu autoryzacji montowania, unieważnienia uchwytów plikowych oraz utraty łączności transportowej.

Komunikat Access denied by server while mounting generowany przez polecenie mount oznacza, że serwer NFS jawnie odrzucił żądanie klienta. Pierwszym krokiem inżyniera powinno być zweryfikowanie adresu IP, z którego klient łączy się z serwerem (np. w środowiskach z routingiem asymetrycznym lub wieloma interfejsami). Następnie na serwerze należy wywołać exportfs -v, aby sprawdzić, czy badany adres IP lub podsieć mieści się w zdefiniowanych maskach CIDR. Częstym źródłem tego błędu jest również próba zamontowania ścieżki, która nie została jawnie wyeksportowana w /etc/exports.

Jednym z najbardziej specyficznych błędów w architekturze NFS jest błąd Stale file handle (kod błędu ESTALE). Wynika on bezpośrednio z natury uchwytów plikowych (File Handles). Kiedy klient otwiera plik, serwer przesyła mu binarny identyfikator zawierający m.in. numer i-węzła (inode) oraz numer generacji. Jeżeli administrator na serwerze skasuje ten plik i utworzy nowy o identycznej nazwie, numer generacji ulegnie zmianie. Klient, próbując zapisać kolejne dane pod starym uchwytem, otrzymuje od serwera informację, że obiekt przestał istnieć. W przypadku wystąpienia błędu ESTALE na całym katalogu jedynym skutecznym rozwiązaniem jest odmontowanie zasobu (często z flagą leniwą umount -l) i ponowne wykonanie procedury montowania.

Warto również zwrócić uwagę na narzędzie nfsstat. Uruchomione z przełącznikiem -c na stacji klienckiej dostarcza bezcennych statystyk dotyczących liczby wykonanych wywołań RPC, liczby retransmisji pakietów (retrans) oraz operacji zaniechanych z powodu przekroczenia limitu czasu. Gwałtowny wzrost licznika retransmisji jednoznacznie wskazuje na przeciążenie interfejsów sieciowych, uszkodzenie okablowania strukturalnego lub błędy w buforach przełączników sieciowych.

Wyjaśnienie skrótów i pojęć:
Stale file handle – nieaktualny uchwyt po usunięciu obiektu na serwerze albo utracie stanu.
Permission denied – odmowa montowania albo zapisu z powodu exports, zapory albo POSIX.
rpcinfo / showmount – inspekcja rejestru RPC oraz listy udziałów zgłaszanej przez mountd.
nfsstat – liczniki operacji i retransmisji wskazujące na utraty pakietów albo przeciążenie.
Wireshark (filtr nfs) – analizator pakietów z filtrami wywołań RPC do weryfikacji opcji i tożsamości.

Przydatne łącza: NFSv4 - RFC 7530; NFSv3 - RFC 1813; ONC RPC - RFC 5531.

Przedstawiona ściągawka stanowi syntetyczne zestawienie najczęściej wykorzystywanych poleceń administracyjnych w ekosystemie Samba. Każdy inżynier zarządzający heterogeniczną siecią LAN powinien biegle operować tymi komendami podczas codziennych prac utrzymaniowych oraz procedur usuwania awarii.

W obszarze diagnostyki konfiguracji bezkonkurencyjną pozycję zajmuje testparm. Polecenie to powinno być uruchamiane automatycznie w ramach procedur CI/CD lub przed każdorazowym wydaniem komendy przeładowania usługi. Z kolei smbstatus stanowi niezastąpione narzędzie weryfikacji wydajnościowej – pozwala błyskawicznie ustalić, ile stacji roboczych aktywnie korzysta z zasobów serwera, które pliki bazy danych są zablokowane oraz czy klienci poprawnie negocjują bezpieczny dialekt SMBv3 z włączonym szyfrowaniem.

W module zarządzania tożsamościami kluczowe jest rozróżnienie pomiędzy poleceniem smbpasswd a narzędziem pdbedit. Podczas gdy smbpasswd służy głównie do szybkiej zmiany hasła przez administratora lub użytkownika, pdbedit jest kompleksowym interfejsem do bazy Security Account Manager (SAM). Umożliwia ono inspekcję parametrów konta, wymuszanie zmiany hasła przy kolejnym logowaniu, modyfikację flag blokady konta oraz precyzyjne definiowanie unikalnych identyfikatorów bezpieczeństwa RID.

W warstwie operacji klienckich uniwersalnym narzędziem pozostaje smbclient, który umożliwia błyskawiczne zweryfikowanie dostępności udziałów z dowolnego węzła w sieci bez konieczności ingerowania w plik /etc/fstab czy modyfikowania lokalnych punktów montowania systemu operacyjnego.

Wyjaśnienie skrótów i pojęć:
samba / smbclient – pakiety serwera oraz klienta SMB w Debian i Ubuntu.
systemctl reload smbd – przeładowanie konfiguracji bez zrywania aktywnych sesji.
smbstatus – podgląd sesji, udziałów i blokad w czasie rzeczywistym.
Get-SmbConnection – podgląd dialektu i szyfrowania sesji w systemie Windows.
net use – mapowanie udziału na literę dysku z opcją trwałości połączenia.

Przydatne łącza: Samba (dokumentacja); smb.conf (Samba Wiki); Microsoft - protokół SMB (MS-SMB2).

Niniejsza ściągawka zamyka moduł dydaktyczny poświęcony sieciowym serwerom plików, gromadząc w jednym miejscu najważniejsze polecenia wykorzystywane do administrowania, monitorowania i diagnozowania środowisk Network File System. Znajomość tych komend jest niezbędna dla zachowania wysokiej dostępności i bezpieczeństwa usług dyskowych w nowoczesnych centrach danych.

W codziennej praktyce administratora serwera NFS najważniejszym poleceniem pozostaje exportfs -arv. Pozwala ono na natychmiastowe zaaplikowanie nowych reguł udostępniania katalogów bez konieczności restartowania jądrowego serwera nfsd, co chroni aktywne sesje maszyn wirtualnych i klastrów obliczeniowych przed przerwaniem transferu danych. Z kolei inspekcja pliku /var/lib/nfs/etab pozwala w ułamku sekundy zweryfikować, czy do eksportu nie wkradły się niebezpieczne opcje, takie jak przypadkowe wyłączenie ochrony root_squash.

W warstwie diagnostyki sieciowej niezastąpionym duetem są programy rpcinfo oraz showmount. Polecenie rpcinfo -p pozwala na natychmiastowe zidentyfikowanie, czy wszystkie kluczowe demony (nfs, mountd, nlockmgr) pomyślnie zarejestrowały się w usłudze rpcbind i na jakich portach nasłuchują. Z kolei polecenie nfsstat dostarcza kluczowych metryk wydajnościowych, ujawniając ewentualne wąskie gardła w warstwie sieciowej lub dyskowej serwera.

Podsumowując cały wykład: protokoły SMB i NFS stanowią dopełniające się technologie sieciowego współdzielenia plików. Podczas gdy Samba (SMBv3) jest bezdyskusyjnym liderem w heterogenicznych środowiskach korporacyjnych integrujących stacje Windows z domeną Active Directory, protokół NFS (szczególnie w wersjach NFSv4.1 i NFSv4.2) stanowi niezrównany standard wydajnościowy dla systemów Linux, farm serwerów aplikacyjnych i platform chmurowych. Prawidłowa konfiguracja bezpieczeństwa – eliminacja SMBv1, wymuszenie szyfrowania i podpisywania pakietów oraz rygorystyczne stosowanie mechanizmu root_squash – stanowi fundament stabilnej i bezpiecznej sieci komputerowej.

Wyjaśnienie skrótów i pojęć:
nfs-kernel-server – pakiet serwera NFS z jądrowym demonem nfsd.
exportfs -arv – standardowa synchronizacja exports z jądrem po każdej zmianie.
showmount -e – lista eksportów zgłaszana przez demona mountd serwera.
mount -t nfs – montowanie eksportu z opcjami wersji, twardości i buforów.
nfsstat / dmesg – statystyki retransmisji oraz komunikaty jądra o błędach montowania.

Przydatne łącza: NFSv4 - RFC 7530; NFSv3 - RFC 1813; Debian - podręczniki (manpages).