Protokół SMB został opracowany przez firmę IBM w latach 80. XX wieku jako protokół udostępniania plików w sieciach LAN. Jego pierwotna wersja była częścią systemu OS/2, a później został przejęty i rozwijany przez Microsoft dla systemu Windows.

NFS został stworzony przez Sun Microsystems w 1984 roku i od samego początku był projektowany jako protokół otwarty, z jawną specyfikacją. Dzięki temu zyskał szerokie wsparcie w środowisku Unix i stał się standardem IEEE w 1998 roku.

Oba protokoły ewoluowały przez dziesięciolecia, dodając coraz bardziej zaawansowane mechanizmy bezpieczeństwa, szyfrowania i optymalizacji wydajności. Współczesne wersje (SMBv3 i NFSv4) oferują funkcje, które jeszcze 10 lat temu były niedostępne w protokołach plikowych.

W środowiskach heterogenicznych, gdzie współistnieją systemy Windows i Linux, administrator musi znać oba protokoły, aby móc skutecznie konfigurować współdzielenie zasobów plikowych między różnymi platformami.

Laboratorium dołączone do tej prezentacji pozwoli na praktyczne skonfigurowanie zarówno serwera Samba, jak i serwera NFS, a także na przetestowanie działania obu protokołów ze strony klienta sieciowego.

Celem warsztatu jest praktyczne przygotowanie administratora do konfiguracji i utrzymania serwerów plików w różnorodnych środowiskach sieciowych. Uczestnik po zakończeniu zajęć powinien samodzielnie skonfigurować zarówno udział Samba, jak i eksport NFS.

Szczególny nacisk położony jest na bezpieczeństwo - uczestnik nauczy się, jak unikać typowych błędów konfiguracyjnych, takich jak niepotrzebne włączenie SMBv1, brak mechanizmu root_squash w NFS czy niepoprawne mapowanie użytkowników.

Wiedza zdobyta podczas warsztatu ma charakter uniwersalny - konfiguracja Samba sprawdzi się zarówno w małej sieci domowej, jak i w dużym środowisku korporacyjnym zintegrowanym z Active Directory.

Umiejętność diagnostyki problemów z udostępnianiem plików jest jedną z najważniejszych kompetencji administratora sieci, ponieważ usługi plikowe są często najbardziej krytycznymi zasobami w organizacji.

Prezentacja została podzielona na sześć bloków tematycznych, które stopniowo budują wiedzę od podstaw teoretycznych po praktyczne umiejętności laboratoryjne. Każda część zawiera elementy interaktywne i przykłady konfiguracji.

W części pierwszej skupimy się na protokole SMB i jego ewolucji - od niebezpiecznego SMBv1 do nowoczesnego SMBv3 z szyfrowaniem AES. Omówione zostaną porty, mechanizmy ataków i metody obrony.

Część druga poświęcona jest Sambie - implementacji SMB dla systemów Unix/Linux. Skonfigurujemy plik smb.conf, omówimy parametry udziałów i integrację z Active Directory.

Część trzecia i czwarta dotyczą protokołu NFS - od architektury RPC, przez wersje NFSv3 i NFSv4, aż po szczegółową konfigurację pliku /etc/exports i mechanizmy bezpieczeństwa, takie jak root_squash.

Najważniejszą częścią jest laboratorium, w którym uczestnicy samodzielnie skonfigurują serwery Samba i NFS, a następnie przetestują je ze strony klientów sieciowych.

Protokół SMB działa w architekturze klient-serwer, gdzie klient wysyła żądania dostępu do plików, a serwer odpowiada, udostępniając żądane dane. Każde żądanie i odpowiedź są pakowane w ramkę SMB zawierającą nagłówek i dane.

Mechanizm oplocks pozwala klientom na buforowanie danych z plików lokalnie, co znacznie zwiększa wydajność. Gdy inny klient chce uzyskać dostęp do tego samego pliku, serwer wysyła break do buforującego klienta, który musi zsynchronizować dane z serwerem.

SMB obsługuje dwa modele autoryzacji: share-level (hasło dostępu do udziału) i user-level (autoryzacja na podstawie konta użytkownika). W nowoczesnych środowiskach dominuje model user-level, często zintegrowany z Active Directory.

Protokół ewoluował od prostego współdzielenia plików do zaawansowanego systemu obsługującego szyfrowanie, wielokanałowość, transparentną failover i integrację z RDMA.

Atak EternalBlue wykorzystywał lukę w implementacji SMBv1 w systemie Windows, umożliwiając zdalne wykonanie kodu (RCE) bez uwierzytelniania. Luka została załatana przez Microsoft w marcu 2017 roku (MS17-010), ale wiele systemów nie zostało zaktualizowanych na czas.

WannaCry, który wykorzystał EternalBlue, zainfekował ponad 200 000 komputerów w 150 krajach w ciągu zaledwie kilku dni. Największe straty poniosły szpitale NHS w Wielkiej Brytanii, hiszpańska Telefonica i niemiecki Deutsche Bahn.

Mimo że Microsoft wydał łatkę dla nawet niewspieranych już systemów (Windows XP), wiele organizacji do dziś nie wyłączyło SMBv1. Głównym powodem są przestarzałe urządzenia sieciowe i aplikacje, które nie działają z nowszymi wersjami SMB.

Zalecenie Microsoftu jest jednoznaczne: SMBv1 powinien być wyłączony na wszystkich kontrolerach domeny, serwerach plików i stacjach roboczych. W razie potrzeby uruchamiania starych aplikacji należy użyć oddzielnej podsieci VLAN z ograniczonym dostępem.

Przebudowa protokołu w SMBv2 była odpowiedzią na rosnące wymagania wydajnościowe i bezpieczeństwa. Redukcja liczby komend nie tylko uprościła implementację, ale także zmniejszyła powierzchnię ataku na protokół.

Pipelining to jedna z najważniejszych optymalizacji SMBv2. W SMBv1 klient musiał czekać na odpowiedź serwera przed wysłaniem kolejnego żądania (serializacja). SMBv2 pozwala na wysyłanie wielu żądań jednocześnie, co znacząco poprawia przepustowość w sieciach z dużym opóźnieniem.

Durable handles to mechanizm, który pozwala na przetrwanie krótkotrwałej przerwy w łączności między klientem a serwerem. Jeśli klient straci połączenie na kilka sekund, jego otwarte pliki pozostają dostępne, a po ponownym połączeniu klient może kontynuować pracę bez utraty danych.

Mimo licznych ulepszeń, SMBv2 jest obecnie uznawany za przestarzały i powinien być używany tylko wtedy, gdy SMBv3 nie jest dostępny z powodu ograniczeń sprzętowych lub programowych.

SMBv3 wprowadza szyfrowanie end-to-end bez konieczności konfigurowania IPsec. Szyfrowanie działa na poziomie protokołu SMB i chroni całą transmisję, w tym uwierzytelnianie i dane. W SMBv3.1.1 dodano szyfrowanie AES-128-GCM, które jest szybsze od CCM na nowoczesnych procesorach.

Multichannel to przełomowa funkcja pozwalająca na agregację przepustowości z wielu kart sieciowych. Jeśli serwer ma dwie karty 10 GbE, SMB może wykorzystać je obie jednocześnie, zapewniając efektywną przepustowość do 20 Gb/s. Dodatkowo multichannel zapewnia odporność na awarię pojedynczej karty.

SMB Direct (RDMA) pozwala na przesyłanie danych bez angażowania procesora gościa (zero-copy). Karty sieciowe RDMA (RoCE v2, iWARP, InfiniBand) mogą przesyłać dane bezpośrednio między pamięcią RAM serwera i klienta, osiągając przepustowość do 200 Gb/s przy minimalnym opóźnieniu.

SMB over QUIC, wprowadzony w Windows Server 2022, umożliwia bezpieczny dostęp do udziałów plikowych przez Internet bez konieczności konfigurowania VPN. QUIC działa na porcie 443 (HTTPS) i jest odporny na blokowanie NAT i firewalle.

Historycznie SMB działał jako usługa na szczycie NetBIOS (Network Basic Input/Output System), który korzystał z protokołu NetBEUI lub TCP/IP przez port 139. W Windows 2000 Microsoft wprowadził możliwość bezpośredniego działania SMB na TCP/IP bez pośrednictwa NetBIOS, używając portu 445.

Współcześnie zarówno Windows, jak i Samba domyślnie używają portu 445. NetBIOS przez port 139 jest wyłączony domyślnie, ale może być włączony dla zgodności ze starszymi aplikacjami lub urządzeniami.

Z punktu widzenia bezpieczeństwa, port 445 powinien być blokowany na firewallu perymetrycznym dla ruchu przychodzącego z Internetu. W sieci wewnętrznej dostęp do SMB powinien być ograniczony tylko do niezbędnych hostów za pomocą list ACL.

Należy pamiętać, że niektóre narzędzia do skanowania sieci (np. Nmap) domyślnie skanują port 445, co czyni go często wykrywanym w testach penetracyjnych jako potencjalny wektor ataku.

Tabela porównawcza wyraźnie pokazuje, jak ogromny postęp dokonał się między SMBv1 a SMBv3. SMBv1 był protokołem zaprojektowanym w erze, gdy sieci LAN były izolowane i bezpieczne, a szyfrowanie nie było priorytetem.

SMBv2 przyniósł optymalizację wydajności (pipelining, durable handles) i redukcję złożoności, ale nadal brakowało mu wbudowanego szyfrowania. To oznacza, że administrator musiał polegać na zewnętrznych mechanizmach, takich jak IPsec, do zabezpieczenia transmisji.

SMBv3 to prawdziwa rewolucja - wprowadza nie tylko szyfrowanie, ale także zaawansowane funkcje wydajnościowe, takie jak multichannel i RDMA. Transparent failover umożliwia budowanie odpornych na awarie klastrów plików bez przerywania sesji klienckich.

SMB over QUIC, dostępny od Windows Server 2022, to kolejny krok ewolucji, umożliwiający bezpieczny dostęp do plików przez Internet z wykorzystaniem protokołu QUIC na porcie 443.

Atak Pass-the-Hash działa, ponieważ protokół NTLM używa skrótu hasła (hash) do uwierzytelnienia. Jeśli atakujący przechwyci hash NTLM (np. z pamięci komputera ofiary), może go użyć bezpośrednio do uwierzytelnienia się na innych systemach w sieci bez znajomości hasła jawnego.

Responder to popularne narzędzie do ataków MITM na protokół SMB. Nasłuchuje on na zapytania NetBIOS, LLMNR i mDNS, a następnie odpowiada, podszywając się pod żądany serwer. Gdy ofiara próbuje się połączyć, Responder przechwytuje hash NTLM.

SMB Relay to bardziej zaawansowany atak, w którym atakujący działa jako pośrednik między ofiarą a serwerem. Przechwytuje uwierzytelnienie NTLM i przekazuje je dalej, uzyskując dostęp do zasobów docelowego serwera.

Obrona przed atakami na SMB wymaga wielowarstwowego podejścia: wyłączenie SMBv1, włączenie szyfrowania SMBv3, stosowanie silnych haseł, ograniczenie dostępu do SMB przez firewall, użycie SMB Signing (podpisywanie pakietów SMB) oraz monitorowanie logów pod kątem podejrzanych prób uwierzytelnienia.

W systemie Windows Server wersję SMB można sprawdzić za pomocą polecenia Get-SmbServerConfiguration w PowerShell. Wynik zawiera pola EnableSMB1Protocol, EnableSMB2Protocol oraz EnableSMB3Protocol (SMBv3 jest domyślnie włączony, gdy SMBv2 jest aktywny).

Do wyłączenia SMBv1 w Windows można użyć: Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol. W Windows Server dodatkowo: Set-SmbServerConfiguration -EnableSMB1Protocol $false.

W Sambie parametry server min protocol i server max protocol są kluczowe dla bezpieczeństwa. Ustawienie server min protocol = SMB2 wyłącza SMBv1 nawet dla klientów, którzy próbują użyć starszego protokołu.

Należy pamiętać, że niektóre starsze urządzenia (np. drukarki sieciowe, systemy embedded) mogą nie obsługiwać SMBv2 lub SMBv3. W takich przypadkach, jeśli nie można zaktualizować oprogramowania urządzenia, należy umieścić je w osobnej podsieci VLAN z ograniczonym dostępem.

Inwentaryzacja to kluczowy pierwszy krok. Należy sprawdzić, które systemy w sieci nadal używają SMBv1. Można to zrobić za pomocą narzędzi takich jak Microsoft Message Analyzer, Wireshark (filtr smb || smb2) lub skryptów PowerShell sprawdzających logi zdarzeń SMB.

W logach Windows należy szukać Event ID 1001 (klient) i 1002 (serwer) w Applications and Services Logs. Wskazują one na próby połączenia z użyciem SMBv1. W Sambie należy sprawdzić logi smbd z poziomem logowania max 2.

Pilotażowa grupa serwerów powinna obejmować serwery nieprodukcyjne lub o niskim priorytecie. Po tygodniu testów i rozwiązaniu problemów ze starszymi aplikacjami, można przystąpić do wyłączania SMBv1 na serwerach produkcyjnych.

Najczęstszym problemem podczas wyłączania SMBv1 są stare urządzenia biurowe (drukarki, skanery, systemy kontroli dostępu), które mają wbudowane oprogramowanie klienckie SMBv1. Dla takich urządzeń należy rozważyć aktualizację firmware'u lub umieszczenie ich w osobnej strefie sieciowej.

Andrew Tridgell, twórca Samba, rozpoczął pracę nad protokołem SMB w 1991 roku, używając sniffera pakietów (tcpdump) do analizy ruchu między PC a serwerem DEC Pathworks. W 1992 roku opublikował pierwszą wersję oprogramowania, które nazwał Samba.

smbd to główny demon Samba odpowiedzialny za obsługę klientów SMB. Zarządza udziałami plików i drukarek, autoryzacją oraz kontrolą dostępu. Każdy klient łączący się z serwerem Samba uruchamia nowy proces smbd.

nmbd zajmuje się obsługą NetBIOS: rejestracją nazw NetBIOS, odpowiadaniem na zapytania name query oraz udziałem w wyborze browse master. Bez nmbd klienci Windows nie będą widzieć serwera Samba w Otoczeniu sieciowym.

winbindd jest niezbędny w środowiskach zintegrowanych z Active Directory. Odpowiada za rozpoznawanie użytkowników i grup AD, mapowanie ich na lokalne identyfikatory UID/GID oraz uwierzytelnianie przez Kerberos.

Plik smb.conf jest podzielony na sekcje, gdzie każda sekcja zaczyna się od nazwy w nawiasach kwadratowych. Sekcja [global] musi wystąpić dokładnie raz i zawiera ustawienia dotyczące całego serwera Samba.

Niektóre z najważniejszych parametrów w sekcji [global] to: workgroup (nazwa grupy roboczej lub domeny), server string (opis serwera), security (user, ads, domain, server), server min protocol (minimalna wersja SMB), log level (poziom szczegółowości logowania) oraz interfaces (interfejsy sieciowe do nasłuchu).

Udziały definiuje się jako osobne sekcje. Dla każdego udziału określa się path (lokalna ścieżka), comment (opis), read only (tylko do odczytu), browseable (widoczny w sieci), guest ok (dostęp bez hasła) i valid users (lista dozwolonych użytkowników).

Narzędzie testparm powinno być uruchamiane po każdej zmianie smb.conf. Wyświetla ono ostrzeżenia o nieprawidłowych parametrach, nieznanych opcjach i potencjalnych problemach konfiguracyjnych.

Model uwierzytelniania Samba opiera się na własnej bazie haseł, która jest oddzielona od systemowej bazy /etc/shadow. Wynika to z faktu, że protokół SMB wymaga dostępu do skrótów haseł w formacie NTLM lub LM, których system Linux domyślnie nie przechowuje.

Hasła w bazie SMB są przechowywane w formie zahashowanej przy użyciu algorytmów NTLMv2. Pliki bazy to zwykle passdb.tdb (w nowszych wersjach) lub smbpasswd (starsze wersje). Bazy .tdb znajdują się w katalogu /var/lib/samba/.

Polecenie smbpasswd -a dodaje nowego użytkownika Samba. Użytkownik musi istnieć w systemie Linux (w /etc/passwd), aby można było dodać go do bazy SMB. Polecenie pdbedit oferuje bardziej zaawansowane opcje zarządzania.

W środowiskach z Active Directory, Samba może delegować uwierzytelnianie do kontrolera domeny AD. Wymaga to ustawienia security = ads, odpowiedniej konfiguracji Kerberosa (/etc/krb5.conf) i wykonania net ads join do domeny.

Parametr path definiuje bezwzględną ścieżkę w systemie plików serwera do katalogu, który ma być udostępniony przez SMB. Katalog musi istnieć i mieć odpowiednie uprawnienia dostępu dla użytkownika, pod którym działa smbd.

Parametr read only = no udostępnia zapis do udziału. Gdy read only = yes (ustawienie domyślne), klienci mogą tylko czytać pliki. Wartość read only = no w połączeniu z guest ok = yes tworzy publiczny udział z pełnym dostępem dla wszystkich.

valid users pozwala na stworzenie listy użytkowników i grup (@nazwa_grupy), którzy mają dostęp do udziału. Wszyscy inni użytkownicy będą odrzuceni. Parametr invalid users działa odwrotnie.

Masks (create mask, directory mask) definiują początkowe uprawnienia dla plików i katalogów tworzonych przez klientów SMB. Działają jak maska AND na uprawnieniach zgłaszanych przez klienta.

Przykładowa konfiguracja zawiera sekcję [global] z podstawowymi ustawieniami serwera Samba. Grupa robocza ASKLAB identyfikuje serwer w sieci, a server string to czytelny opis wyświetlany klientom.

Parametr security = user oznacza, że każdy użytkownik musi podać hasło SMB przy połączeniu, chyba że udział ma guest ok = yes.

Parametr server min protocol = SMB2 wyłącza SMBv1, co znacząco zwiększa bezpieczeństwo serwera. Klienci próbujący użyć SMBv1 otrzymają błąd negocjacji protokołu.

Udział [Publiczny] jest dostępny dla wszystkich (guest ok = yes) i tylko do odczytu. Udział [Prywatny] jest dostępny tylko dla użytkownika ala z pełnym dostępem do zapisu.

smbstatus to podstawowe narzędzie monitorujące dla administratora Samba. Pokazuje listę aktywnych połączeń (z adresami IP klientów), otwarte pliki i zablokowane zakresy plików.

smbclient to wszechstronne narzędzie klienckie, które działa podobnie do klienta FTP. Po połączeniu do udziału, użytkownik może używać komend takich jak ls, cd, get, put, mkdir, rm do zarządzania plikami.

Montowanie SMB przez mount -t cifs wymaga zainstalowanego pakietu cifs-utils. Standardowe opcje montowania to: username, password, domain, uid/gid, sec (ntlm, ntlmv2, krb5) oraz vers (1.0, 2.0, 2.1, 3.0).

testparm to niezbędne narzędzie do walidacji konfiguracji przed ponownym uruchomieniem smbd. Wyświetla ostrzeżenia o przestarzałych parametrach i potencjalnych problemach.

Integracja Samba z Active Directory to jeden z ważniejszych scenariuszy w środowiskach heterogenicznych. Dzięki niej serwer Linux z Sambą może udostępniać pliki z wykorzystaniem użytkowników i grup zdefiniowanych w AD.

Proces rozpoczyna się od konfiguracji Kerberosa w pliku /etc/krb5.conf. Należy poprawnie ustawić realm (wielkimi literami) oraz serwery KDC. Działanie Kerberosa można przetestować za pomocą kinit administratora.

Po skonfigurowaniu smb.conf z security = ads i uruchomieniu smbd, wykonujemy net ads join -U Administrator. To polecenie tworzy konto komputerowe w AD, ustawia SPN i zapisuje klucz Kerberosa w /etc/krb5.keytab.

Po uruchomieniu winbindd, polecenie getent passwd powinno pokazać użytkowników AD z zakresem UID zdefiniowanym w smb.conf. Udziały Samba mogą teraz używać nazw użytkowników AD w parametrach valid users.

Poziom logowania (log level) jest kluczowy dla diagnostyki. Przy poziomie 0-1 logowane są tylko krytyczne błędy. Poziom 2-3 dodaje informacje o połączeniach i uwierzytelnianiu.

Pliki logów Samba znajdują się w /var/log/samba/. Każdy demon (smbd, nmbd, winbindd) ma swój osobny plik logu. W przypadku problemów z dostępem do udziału, należy przede wszystkim sprawdzić log.smbd.

Weryfikacja działania smbd za pomocą ss -tlnp | grep smbd powinna pokazać nasłuch na porcie 445. Jeśli smbd nie nasłuchuje, należy sprawdzić, czy demon jest uruchomiony i czy firewall nie blokuje portu.

Problemy z uwierzytelnianiem są często spowodowane brakiem użytkownika w bazie SMB, różnicą między hasłem systemowym a SMB lub błędną konfiguracją security w smb.conf.

NFS został zaprojektowany jako protokół otwarty - jego specyfikacja była publicznie dostępna od samego początku. Dzięki temu różni producenci mogli implementować NFS we własnych systemach operacyjnych.

Architektura RPC (Remote Procedure Call) jest sercem NFS. Gdy klient chce odczytać plik, wywołuje funkcję READ z parametrami (handle pliku, offset, długość), która jest przetłumaczona na żądanie RPC i wysłana do serwera.

Różnica między podejściem bezstanowym (NFSv3) a stanowym (NFSv4) jest fundamentalna. W NFSv3 każde żądanie jest niezależne, podczas gdy w NFSv4 klient i serwer utrzymują stan sesji.

NFS jest integralną częścią systemów Unix/Linux od dziesięcioleci. Współczesne dystrybucje Linuksa używają implementacji NFS jądra (nfsd), która oferuje wysoką wydajność dzięki działaniu w przestrzeni jądra.

Architektura RPC w NFS działa w następujący sposób: gdy demon nfsd uruchamia się na serwerze, rejestruje w rpcbind program RPC o numerze 100003 wraz z obsługiwanymi wersjami protokołu.

Klient, który chce zamontować eksport NFS, najpierw łączy się z rpcbind na porcie 111 i pyta o program 100003. rpcbind zwraca numer portu, na którym działa nfsd.

Dodatkowo klient pyta rpcbind o program 100005 (mountd), który obsługuje żądania montowania. mountd weryfikuje, czy klient ma prawo zamontować żądany eksport i zwraca filehandle.

W NFSv4 architektura uległa uproszczeniu. rpcbind jest nadal używany, ale mountd nie jest już potrzebny do początkowego montowania - funkcje montowania są zintegrowane z NFSv4.

NFSv2, opublikowany w 1984 roku, był pierwszą implementacją protokołu zdalnego dostępu do plików. Działał wyłącznie przez UDP, co ograniczało go do sieci lokalnych o niskim opóźnieniu.

NFSv3, zdefiniowany w RFC 1813, był znaczącym ulepszeniem. Wprowadził obsługę TCP, 64-bitowe przesunięcia plików, zapis asynchroniczny i ulepszone mechanizmy blokad.

NFSv4 (RFC 3530) był kompletną przebudową protokołu. Wprowadził stanowość (sesje), zintegrowane blokady plików oraz obowiązkowe wsparcie dla bezpieczeństwa RPCSEC_GSS (Kerberos).

NFSv4.1 wprowadził pNFS (Parallel NFS), który umożliwia równoległy dostęp do danych przez wiele serwerów danych zarządzanych przez jeden serwer metadanych. To przełomowe rozwiązanie dla klastrów obliczeniowych i HPC.

Różnica w stanowości między NFSv3 a NFSv4 jest fundamentalna. W NFSv3 serwer nie przechowuje żadnych informacji o stanie klienta. W przypadku restartu serwera, klient po prostu ponawia żądania.

Największą praktyczną różnicą jest kwestia portów i firewalla. NFSv3 używa dynamicznych portów dla różnych usług, co utrudnia konfigurację firewalla. NFSv4 używa głównie portu TCP 2049.

Bezpieczeństwo to kolejna kluczowa różnica. NFSv3 domyślnie używa AUTH_SYS, który przesyła UID i GID użytkownika w czystym tekście. NFSv4 wymusza użycie RPCSEC_GSS z Kerberosem.

Delegacje w NFSv4 pozwalają klientowi na buforowanie danych plików lokalnie przez określony czas. Serwer deleguje klientowi prawa do pliku, co znacząco poprawia wydajność przy częstych odczytach.

RPCSEC_GSS (Generic Security Services) to warstwa bezpieczeństwa dla protokołu RPC, która abstrahuje od konkretnych mechanizmów kryptograficznych. W przypadku NFSv4 najczęściej używanym mechanizmem jest Kerberos v5.

Tryb krb5 zapewnia tylko uwierzytelnienie - serwer wie, kim jest klient, ale dane są przesyłane w czystym tekście. Tryb krb5i dodaje integralność, a krb5p szyfruje całą transmisję.

NFSv4 ACL to znacznie bardziej zaawansowany mechanizm kontroli dostępu niż tradycyjne uprawnienia Unix. Pozwala na definiowanie reguł allow i deny dla poszczególnych użytkowników i grup.

Demon idmapd pełni kluczową rolę w mapowaniu identyfikatorów. Gdy klient uwierzytelniony przez Kerberos próbuje uzyskać dostęp do pliku, idmapd na serwerze tłumaczy nazwę na lokalny UID.

Wybór między SMB a NFS zależy przede wszystkim od platformy klienckiej. W środowisku czysto Windowsowym naturalnym wyborem jest SMB. W środowisku czysto Linuksowym naturalnym wyborem jest NFS.

SMB oferuje lepszą integrację z Active Directory, przeglądarkę sieciową i prostsze mapowanie dysków dla użytkowników Windows. NFS oferuje lepszą wydajność i mniejsze narzuty w systemach Unix/Linux.

W praktyce wiele organizacji stosuje podejście hybrydowe: serwer plików z Sambą dla klientów Windows i serwer NFS dla klientów Linux.

Z punktu widzenia bezpieczeństwa, oba protokoły w najnowszych wersjach oferują solidne mechanizmy: SMBv3 z szyfrowaniem AES i NFSv4 z Kerberos krb5p.

Implementacja NFS w jądrze Linuksa (nfsd) oferuje znacznie lepszą wydajność niż implementacje w przestrzeni użytkownika, ponieważ operacje plikowe są wykonywane bezpośrednio w kontekście jądra.

Po uruchomieniu nfs-kernel-server, proces nfsd tworzy wiele wątków (domyślnie 8) do obsługi żądań klientów. Liczbę wątków można skonfigurować w pliku /etc/default/nfs-kernel-server (RPCNFSDCOUNT).

Wynik polecenia rpcinfo -p pokazuje wszystkie programy RPC zarejestrowane w rpcbind. Dla serwera NFS powinniśmy zobaczyć: 100003 (nfs), 100005 (mountd), 100021 (nlockmgr) i 100011 (rquotad).

W NFSv4 port 2049 jest używany dla programu nfs (100003), a dodatkowe usługi (mountd, nlockmgr) mogą nie być potrzebne, ponieważ ich funkcje są zintegrowane z protokołem NFSv4.

W NFSv4 identyfikatory użytkowników i grup są przesyłane jako stringi w formacie user@domain, a nie jako numeryczne UID/GID jak w NFSv3. To eliminuje problem różnych UID dla tego samego użytkownika na różnych maszynach.

Demon rpc.idmapd obsługuje mapowanie w obie strony: z nazwy użytkownika na UID i z UID na nazwę.

Plik /etc/idmapd.conf wymaga poprawnego ustawienia parametru Domain. Wartość Domain musi być taka sama na kliencie i na serwerze, aby mapowanie działało poprawnie.

W przypadku problemów z mapowaniem, należy sprawdzić logi idmapd w /var/log/syslog i użyć nfsidmap -c do czyszczenia cache.

Demon mountd jest nieodłączną częścią serwera NFSv3. Gdy klient próbuje zamontować eksport, mountd najpierw sprawdza plik /etc/exports, aby upewnić się, że klient ma odpowiednie uprawnienia.

Filehandle (uchwyt plikowy) to nieprzezroczysty identyfikator pliku lub katalogu używany przez NFS do identyfikacji zasobów. W NFSv3 filehandle jest generowany przez mountd.

W NFSv4 proces montowania jest znacznie prostszy. Klient łączy się bezpośrednio z demonem nfsd na porcie TCP 2049 i używa zintegrowanych operacji protokołu.

W NFSv3 można ustalić stały port dla mountd, dodając opcję -p w pliku /etc/default/nfs-kernel-server. To ułatwia konfigurację firewalla.

Pseudo filesystem to jedna z najważniejszych innowacji NFSv4. W NFSv3 każdy eksport był montowany osobno, co wymagało wielu wpisów w /etc/fstab i osobnych punktów montowania.

W NFSv4 klient montuje główny katalog serwera (server:/) i widzi wszystkie dostępne dla siebie eksporty jako podkatalogi. Serwer prezentuje widok zależny od uprawnień klienta.

Mechanizm fs_location w NFSv4.1 pozwala na przekierowanie klienta do innego serwera dla konkretnego eksportu, co umożliwia budowanie rozproszonych systemów plików.

Pseudo filesystem eliminuje problem rozbieżności między strukturą katalogów na serwerze a sposobem jej prezentacji klientom, co było częstym źródłem błędów w konfiguracji NFSv3.

Plik /etc/exports jest podstawowym mechanizmem definiowania zasobów udostępnianych przez NFS. Każda linia definiuje jeden eksport - ścieżkę katalogu na serwerze i listę klientów z opcjami dostępu.

Klient może być określony jako pojedynczy adres IP (192.168.56.10), podsieć CIDR (192.168.56.0/24), nazwa DNS (klient.asklab.local) lub domena (*.asklab.local). Znak * oznacza wszystkich klientów.

Po każdej zmianie /etc/exports należy uruchomić exportfs -arv, który odczytuje plik ponownie i aktualizuje listę eksportów w jądrze bez restartu usługi nfs-kernel-server.

Polecenie exportfs -v wyświetla aktualną listę eksportów wraz z opcjami, a showmount -e localhost pokazuje, jakie eksporty są dostępne dla klientów na danym serwerze.

Opcja sync (domyślnie od NFSv4) wymusza synchroniczny zapis na serwerze - serwer potwierdza zapis dopiero po fizycznym zapisaniu danych na dysk. async pozwala na potwierdzenie przed zapisem, co zwiększa wydajność, ale ryzykuje utratę danych przy awarii.

no_subtree_check to ważna optymalizacja wydajności. Gdy jest włączona (domyślnie od NFSv4), serwer nie sprawdza, czy żądany plik faktycznie znajduje się w eksportowanym katalogu. Wyłączenie tego sprawdzania zwiększa wydajność.

Opcja no_wdelay wyłącza opóźnienie zapisu. Gdy serwer otrzymuje wiele małych zapisów do różnych plików, domyślnie grupuje je (wdelay). no_wdelay zapisuje każdy zapis natychmiast.

Opcje nohide, secure, insecure i insecure_locks są rzadziej używane, ale mogą być potrzebne w specyficznych konfiguracjach. Zazwyczaj domyślne ustawienia są wystarczające dla większości zastosowań.

Mechanizm root_squash jest najważniejszym zabezpieczeniem w NFS. Działa na zasadzie mapowania UID 0 (root) z klienta na lokalnego użytkownika anonimowego (zazwyczaj nobody lub nfsnobody) z minimalnymi uprawnieniami.

Gdy root_squash jest wyłączony (no_root_squash), root z klienta NFS ma pełne uprawnienia roota na serwerze. Oznacza to, że po skompromitowaniu dowolnego klienta, atakujący ma pełny dostęp do wszystkich plików na serwerze NFS.

Opcja all_squash jest użyteczna w scenariuszach, gdzie wszyscy klienci powinni mieć identyczne uprawnienia, na przykład dla anonimowego dostępu publicznego do zasobów tylko do odczytu.

Parametry anonuid i anongid pozwalają na precyzyjne określenie, jakiego lokalnego użytkownika i grupę ma otrzymać anonimowy klient. Dzięki temu można kontrolować, jakie uprawnienia będą mieli klienci bez własnego konta na serwerze.

exportfs to podstawowe narzędzie administracyjne NFS. Uruchomione bez argumentów pokazuje aktualną listę eksportów. Opcja -arv odczytuje na nowo plik /etc/exports i synchronizuje listę eksportów w jądrze.

showmount to narzędzie klienckie do odpytywania serwera NFS o dostępne eksporty. Opcja -e wyświetla listę wszystkich eksportów, a -a pokazuje, które eksporty są aktualnie zamontowane przez których klientów.

Po usunięciu eksportu z /etc/exports i wykonaniu exportfs -arv, klienci, którzy mają go zamontowany, nadal mają dostęp, ale nowi klienci nie będą mogli go zamontować.

W NFSv4 showmount może nie działać poprawnie, ponieważ rejestracja eksportów odbywa się przez inny mechanizm. W takim przypadku lepiej użyć exportfs -v do weryfikacji dostępnych eksportów.

Przykładowa konfiguracja /etc/exports pokazuje różne scenariusze użycia. Eksport publiczny (/srv/nfs/public) jest dostępny dla całej podsieci 192.168.56.0/24 tylko do odczytu.

Eksport prywatny (/srv/nfs/private) jest dostępny tylko dla jednego konkretnego klienta (192.168.56.10) z pełnym dostępem do zapisu i włączonym root_squash dla bezpieczeństwa.

Eksport backup (/srv/nfs/backup) ma wyłączony root_squash, co oznacza, że root z klienta backupu ma pełne uprawnienia na serwerze. To celowe działanie, ponieważ narzędzia backupowe często wymagają dostępu jako root.

Opcja *.asklab.local w eksporcie /home oznacza, że każdy klient z domeny asklab.local może zamontować ten katalog. To wygodne, ale wymaga działającego DNS dla poprawnej weryfikacji nazw.

Różnica między opcjami hard i soft ma istotne znaczenie praktyczne. Przy hard klient będzie próbował w nieskończoność, aż serwer odpowie. Przy soft klient podda się po określonej liczbie prób i zwróci błąd aplikacji.

Opcja intr pozwala na przerwanie działania procesu, który czeka na odpowiedź NFS, za pomocą Ctrl+C lub SIGINT. Bez tej opcji proces zawiesza się na stałe, a jedynym rozwiązaniem jest zamknięcie go przez kill -9.

Opcja timeo określa czas oczekiwania na odpowiedź serwera. Wartość jest wyrażona w dziesiątkach sekund (timeo=7 = 0,7s). Po przekroczeniu czasu klient ponawia żądanie. Dla sieci LAN wartość 2-5 jest odpowiednia.

Opcja bg jest przydatna przy montowaniu w /etc/fstab. Jeśli serwer jest niedostępny podczas uruchamiania, bg przenosi montowanie do tła i nie blokuje procesu bootowania. Po restaurcie system uruchomi się poprawnie, a eksport zostanie zamontowany później.

Trwałe montowanie NFS przez /etc/fstab jest standardowym sposobem zapewnienia dostępu do zdalnych zasobów plikowych po każdym restarcie systemu. Opcja _netdev jest krytyczna - bez niej system może próbować zamontować eksport przed uruchomieniem sieci.

W systemach z systemd, każdy wpis w /etc/fstab jest automatycznie konwertowany na jednostkę .mount. Dzięki temu można zarządzać montowaniem NFS za pomocą systemctl.

Opcja noauto jest przydatna dla eksportów, które nie są potrzebne przy starcie systemu. Można je zamontować ręcznie za pomocą mount /punkt lub automatycznie przy pierwszym dostępie (autofs).

W przypadku częstych problemów z montowaniem NFS przy starcie, warto rozważyć użycie autofs, które montuje eksport tylko wtedy, gdy jest faktycznie potrzebny, co eliminuje problemy z kolejnością uruchamiania usług.

pNFS to przełomowe rozszerzenie NFS, które adresuje problem wąskiego gardła tradycyjnego NFS. W standardowym NFS wszystkie operacje plikowe przechodzą przez jeden serwer, co ogranicza przepustowość.

W architekturze pNFS, serwer metadanych (Metadata Server lub Control MDS) przechowuje tylko informacje o strukturze plików i katalogów. Gdy klient chce odczytać plik, pyta MDS o layout, który wskazuje, na których serwerach danych znajdują się bloki pliku.

Klient komunikuje się bezpośrednio z serwerami danych (Data Servers) używając protokołu zgodnego z rodzajem używanego systemu plików (file layout, block layout, object layout). To eliminuje pośrednictwo serwera metadanych.

pNFS oferuje liniową skalowalność: dodanie kolejnych serwerów danych proporcjonalnie zwiększa całkowitą przepustowość systemu. Dzięki temu pNFS jest idealnym rozwiązaniem dla środowisk HPC i dużych klastrów obliczeniowych.

Laboratorium zostało zaprojektowane jako praktyczne uzupełnienie teorii przedstawionej w poprzednich slajdach. Uczestnicy będą mieli okazję samodzielnie skonfigurować oba protokoły i przetestować ich działanie.

Do laboratorium potrzebne są dwie maszyny wirtualne z systemem Ubuntu 22.04 LTS. Można użyć VirtualBox z siecią Host-Only lub NAT. Ważne, aby maszyny mogły się komunikować między sobą.

Serwer pełni rolę udostępniacza zasobów plikowych przez oba protokoły. Klient będzie montował i testował dostęp do udostępnionych katalogów.

Przed rozpoczęciem laboratorium należy upewnić się, że firewalle na obu maszynach nie blokują niezbędnych portów (445 dla SMB, 2049 i 111 dla NFS).

Konfiguracja udziału publicznego Samba jest najprostszym scenariuszem. Udział będzie dostępny dla wszystkich bez konieczności podawania hasła, ale tylko do odczytu.

Po instalacji Samba, demon smbd uruchamia się automatycznie. Domyślny plik smb.conf zawiera kilka przykładowych udziałów, ale dla naszego laboratorium dodamy własne.

Ważne jest ustawienie odpowiednich uprawnień do katalogu /srv/samba/public. Ponieważ udział jest publiczny, katalog musi być czytelny dla wszystkich (chmod 755 lub 777).

Po restarcie smbd, polecenie smbclient -L z klienta powinno pokazać udział Publiczny na liście dostępnych zasobów. Opcja -U% oznacza anonimowe połączenie bez hasła.

Udział prywatny wymaga uwierzytelnienia. Najpierw tworzymy użytkownika w systemie Linux, a następnie dodajemy go do bazy SMB za pomocą smbpasswd -a. Hasło SMB może być inne niż hasło systemowe.

Parametr valid users = ala w smb.conf ogranicza dostęp do udziału tylko dla tego jednego użytkownika. Można również podać grupę (@nazwa_grupy) lub listę użytkowników oddzielonych spacją.

Po restarcie smbd, próba połączenia bez podania hasła (-U%) powinna się nie powieść, a z użytkownikiem ala i poprawnym hasłem powinna zadziałać.

Po udanym połączeniu za pomocą smbclient, użytkownik może używać komend FTP-podobnych (ls, cd, get, put, mkdir) do zarządzania plikami w udziale prywatnym.

Weryfikacja działania Samba ze strony klienta powinna obejmować kilka testów. Test 1 sprawdza dostęp anonimowy do udziału publicznego, który powinien działać bez hasła.

Test 2 sprawdza, czy udział prywatny faktycznie odrzuca anonimowe połączenia. Test 3 weryfikuje poprawne działanie uwierzytelniania z poprawnym hasłem.

Test 4 pokazuje montowanie SMB jako systemu plików za pomocą mount -t cifs. To najczęstszy sposób korzystania z udziałów SMB w systemie Linux - zamontowany katalog jest widoczny w systemie plików.

Test 5 sprawdza uprawnienia zapisu. Jeśli udział jest skonfigurowany poprawnie, użytkownik ala może tworzyć pliki w udziale prywatnym.

Po instalacji nfs-kernel-server, demon nfsd uruchamia się automatycznie. Należy sprawdzić, czy rpcbind również działa, ponieważ jest niezbędny do rejestracji usług RPC.

Tworzymy trzy katalogi do celów laboratoryjnych: publiczny (tylko do odczytu), prywatny (z root_squash) i testowy (do sprawdzenia root_squash).

W pliku /etc/exports definiujemy dwa eksporty: publiczny dostępny dla całej podsieci tylko do odczytu, i prywatny dostępny tylko dla klienta 192.168.56.10 z pełnym dostępem.

Po dodaniu wpisów do /etc/exports, wykonujemy exportfs -arv, który odświeża listę eksportów bez restartu usługi. Polecenie exportfs -v powinno pokazać skonfigurowane eksporty.

Test 1 i 2 weryfikują, czy eksport publiczny działa tylko do odczytu. Próba utworzenia pliku na read-only eksporcie powinna zakończyć się błędem Read-only file system.

Test 3 montuje eksport prywatny, który ma włączony root_squash. Oznacza to, że root na kliencie (UID 0) zostanie zmapowany na anonimowego użytkownika na serwerze.

Test 4 i 5 są kluczowe dla zrozumienia root_squash. Nawet root na kliencie nie może tworzyć plików jako root na serwerze - właścicielem pliku będzie nobody (lub nfsnobody), co demonstruje działanie mechanizmu root_squash.

Test 6 z showmount -a pokazuje aktywne montowania ze strony serwera. To przydatne narzędzie do monitorowania, którzy klienci aktualnie korzystają z zasobów NFS.

Problem różnych UID dla tego samego użytkownika na różnych maszynach jest jednym z najczęstszych źródeł problemów z NFS. Gdy UID się nie zgadzają, użytkownik widzi pliki jako własność nieznanego użytkownika i może nie mieć do nich dostępu.

Najprostszym rozwiązaniem jest ręczna synchronizacja UID między maszynami (useradd -u UID lub usermod -u UID). W większych środowiskach warto użyć centralnego systemu zarządzania tożsamością (LDAP, FreeIPA).

W NFSv4 problem jest łagodzony przez idmapd, który tłumaczy nazwy użytkowników na UID/GID. Wymaga to poprawnej konfiguracji /etc/idmapd.conf z tą samą wartością Domain na wszystkich maszynach.

W NFSv3 można użyć opcji anonuid/anongid w /etc/exports, aby zmapować wszystkich użytkowników (lub tylko anonimowych) na jednego konkretnego użytkownika na serwerze.

Firewall jest częstą przyczyną problemów z dostępem do udziałów SMB i NFS. Dla SMB należy upewnić się, że port TCP 445 jest otwarty na serwerze. Niektóre środowiska blokują ten port na firewallu wewnętrznym.

NFSv3 jest szczególnie problematyczny dla firewalla ze względu na dynamiczne porty usług RPC. mountd i nlockmgr mogą otrzymać dowolny port od rpcbind. Rozwiązaniem jest ustawienie stałych portów w plikach konfiguracyjnych.

NFSv4 znacznie upraszcza konfigurację firewalla, ponieważ wymaga tylko portu TCP 2049 dla nfsd i opcjonalnie 111 dla rpcbind. To jedna z głównych zalet NFSv4 nad NFSv3 w środowiskach z restrykcyjnym firewallem.

Narzędzie nc (netcat) jest niezastąpione przy testowaniu dostępności portów. Opcja -vz (verbose, zero-I/O) sprawdza, czy port jest otwarty bez wysyłania danych. UFW na serwerze można skonfigurować poleceniem ufw allow 445/tcp.

Większość problemów z Sambą wynika z błędów w pliku smb.conf. Zawsze uruchamiaj testparm po zmianach. Narzędzie to wyświetli ostrzeżenia o nieprawidłowych parametrach i potencjalnych problemach.

Jeśli smbd nie nasłuchuje na porcie 445, sprawdź czy demon jest uruchomiony (systemctl status smbd) i czy nie ma konfliktu portów z inną usługą. Logi smbd znajdują się w /var/log/samba/log.smbd.

Problemy z NetBIOS są częste w nowoczesnych sieciach, gdzie firewalle blokują UDP 137-138. Rozwiązaniem jest użycie bezpośredniego SMB przez port 445, który nie wymaga NetBIOS.

Klienci Windows mogą nie widzieć serwera Samba w Otoczeniu sieciowym, jeśli nmbd nie działa lub jeśli sieć ma włączoną izolację NetBIOS. W takim przypadku należy połączyć się bezpośrednio przez nazwę serwera lub adres IP.

Pierwszym krokiem diagnostyki NFS jest sprawdzenie, czy rpcbind działa. Bez niego żaden serwer NFS nie zarejestruje swoich usług RPC. Polecenie rpcinfo -p localhost powinno pokazać listę zarejestrowanych programów.

Jeśli exportfs -v nie pokazuje żadnych eksportów, sprawdź plik /etc/exports pod kątem błędów składni. Każda linia musi mieć poprawną ścieżkę, listę klientów i opcje w nawiasach.

Problemy z montowaniem NFS ze strony klienta mogą wynikać z blokady portów na firewallu, braku odpowiedzi z rpcbind lub błędnej konfiguracji /etc/exports. Użyj rpcinfo -p adres_serwera do sprawdzenia dostępności RPC.

Konflikt wersji NFS występuje, gdy klient próbuje użyć mount -t nfs4 (NFSv4) do serwera obsługującego tylko NFSv3. Rozwiązaniem jest użycie mount -t nfs z opcją vers=3.

Ściągawka SMB zawiera najważniejsze polecenia używane podczas konfiguracji i diagnostyki serwera Samba. Warto zapamiętać smbclient -L do szybkiego sprawdzenia dostępnych udziałów na zdalnym serwerze.

Montowanie SMB przez mount -t cifs wymaga pakietu cifs-utils na kliencie. Opcja username=user wymaga hasła, które można podać interaktywnie lub w pliku /etc/fstab z opcją credentials=/etc/smb-credentials.

testparm powinien być uruchamiany po każdej zmianie smb.conf. Wyświetla on ostrzeżenia o potencjalnych problemach i różnicach między ustawieniami domyślnymi a skonfigurowanymi.

smbstatus to podstawowe narzędzie monitorujące dla administratora Samba. Pokazuje, którzy klienci są aktualnie połączeni, z jakich udziałów korzystają i jakie pliki mają otwarte.

Ściągawka NFS zawiera kluczowe polecenia do administracji i diagnostyki. exportfs -arv to najważniejsze polecenie, które odświeża listę eksportów po zmianie /etc/exports bez restartu usługi.

showmount -e to szybki sposób na sprawdzenie, jakie eksporty są dostępne na zdalnym serwerze. W NFSv4 może nie działać poprawnie - wtedy użyj exportfs -v na samym serwerze.

rpcinfo -p to niezbędne narzędzie diagnostyczne do sprawdzenia, które usługi RPC są zarejestrowane i na jakich portach działają. Przydatne szczególnie przy konfiguracji firewalla dla NFSv3.

Podsumowując: Samba i NFS to dwa najważniejsze protokoły współdzielenia plików w sieci. Znajomość obu jest niezbędna dla administratora w środowiskach heterogenicznych. Pamiętaj o bezpieczeństwie: wyłącz SMBv1, używaj root_squash w NFS, zawsze testuj konfigurację przed wdrożeniem produkcyjnym.