| Siec TCP/IP || Otoczenie Sieciowe || Poczta || Usnet || FTP || Konto Shellowe || Czat || IRC || Serwer PROXY |

Otoczenie sieciowe - Sieć SMB

utworzono: 24/06/2002 :: modyfikacja: 01/085/2008
autor: Marcin Moczkowski :: glappo (at) banita (dot) pl

Dodatkowy opis tyczący haseł SMB

Hasła kodowane/niekodowane

W otoczeniu sieciowym hasła na konta SMB czyli do udostępnień katalogów, drukarek oraz służące do logowania w domenie NT, mogą być przesyłane w postaci zaszyfrowanej lub niezaszyfrowanej. Oczywiście hasła zaszyfrowane są dużo bardziej bezpieczne niż hasło niezaszyfrowane, które można łatwo odczytać za pomocą programu przechwytujących czyli snifferów. Sposób przesyłania haseł zależy od systemu operacyjnego i praktycznie nie jest możliwa autoryzacja miedzy komputerami używającymi haseł zaszyfrowanych i niezaszyfrowanych. Poniższa tabela przedstawia domyślne tryby przesyłania haseł kodowanych i niekodowanych oraz rodzaje haszów dla haseł kodowanych. Miej na uwadze że są to domyślne wartości, gdyż możliwości danych systemów są dużo większe jak można dalej doczytać.

System operacyjny

Hasła (domyślnie)

Windows for Workgroup 3.11
Windows 95
Windows 95 z uaktualnieniem SMB
Windows 98/Milenium
Windows NT 3.x/4.0 przed SP3
Windows NT 4.0 po SP3
Windows 2000/XP
Windows 2003
Samba 2.0/2.2/3.0

Niezaszyfrowane
Niezaszyfrowane
Zaszyfrowane (
LANMAN)
Zaszyfrowane (
LANMAN)
Niezaszyfrowane
Zaszyfrowane (
LANMAN, NTLM)
Zaszyfrowane (LANMAN, NTLM)
Zaszyfrowane (NTLMv2)
Zaszyfrowane (LANMAN, NTLM)

Oczywiście są to ustawienia domyślne i można je modyfikować za pomocą plików rejestru w systemach Windows lub odpowiedniej deklaracji w pliku smb.conf  w Sambie. Obecnie dąży się do tego żeby przesyłane hasła SMB były szyfrowane i tak też jest w naszej sieci.

Systemy Windows

W systemach Windows zmianę szyfrowania haseł ustawiasz za pomocą rejestru systemu. W celu modyfikacji ustawień szyfrowania bądź nie haseł, pobierz i uruchom poniższe pliku rejestru. Oczywiście nie musisz włączać zaszyfrowanych haseł w systemach, które domyślnie takie przesyłają.
Zmiana haseł z nie szyfrowanych na szyfrowane Zmiana haseł z szyfrowanych na nie szyfrowane
Windows 95/98/Me - Win98_EncPassword.reg
Windows NT 4.0 po SP3 - WinNT4_EncPassword.reg

Windows 2000/XP/2003 - Win2000_EncPassword.reg
Windows 95/98/Me - Win98_PlainPassword.reg
Windows NT 4.0 po SP3 - WinNT4_PlainPassword.reg
Windows
2000/XP/2003 - Win2000_PlainPassword.reg

Pliki te modyfikują jedną wartość w gałęzi rejestru.

Dla Windows 95/98/Me:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP

Dla Windows NT 4.0 SP3 i późniejsze:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters

Dla Windows 2000/XP/2003:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkStation\Parameters

Ustawienie tutaj wartości DWORD "EnablePlainTextPassword" na 0 włącza szyfrowane, a 1 wyłącza szyfrowanie czyli włącza przesyłanie haseł czystym tekstem.

Systemy Windows niezależnie czy używają haseł szyfrowanych czy nie szyfrowanych korzystają z jednej bazy haseł. Dla Windows 95/98/Me są to pliki PWL (nazwane tak od rozszerzenia) znajdujące się z reguły w głównym katalogu systemu. Natomiast dla Windows NT 4.0/2000/XP/2003 jest to baza SAM.

Systemy Samba/Unix

W Sambie o tym czy hasła są szyfrowane czy nie decyduje ustawienie jednej wartości która domyślnie od wersji 2.0 jest ustawiona jako `encrypt passwords = yes`, co sprawia że Samba używa szyfrowanych haseł. Ale za to w systemie posiadamy wtedy dwie bazy haseł, jedna oparta o passwd/shadows dla użytkowników systemowych a drugą kontrolowaną przez Sambę (np. smbpasswd). Można w tym wypadku używać opcji `unix password sync = yes` do synchronizacji tych dwu baz haseł, ale trzeba mieć na uwadze że synchronizacja następuje tylko w jedna stronę Samba =>> Unix. W druga stronę czyli Unix =>> Samba jest to nie możliwe.

Oczywiście ustawienia `encrypt passwords = no` wyłącza szyfrowanie haseł. Nie jest zaleca ale jest częstą praktyką gdyż wtedy Samba nie musi używać swojej bazy haseł, a korzysta z bazy haseł systemowych zawartych w systemach Unix z reguły z plikach passwd/shadows. Jest to wygodne (jedna baza haseł o której synchronizacje nie trzeba dbać) ale niebezpieczne. dodaktowo w tym wypadku możemy używać kontroli PAM nad kontem i sesją włączaną za pomocą opcji `obey pam restrictions = yes`.

Podczas migracji z haseł nie szyfrowanych do szyfrowanych w Sambie warto użyć opcji `update encrypted = yes` gdy mamy jeszcze ustawione `encrypt passwords = no`. Spowoduje to budowanie zaszyfrowanej bazy haseł gdy uzytkownicy podczas normalnej pracy będą się uwierzytelnić w Sambie. Gdy stwierdzimy już że w pliku haseł zaszyfrowanych Samby (zazwyczaj smbpasswd) są już zawarte wszystkie hasła, możemy ustawić szyfrowanie haseł w Sambie czyli `encrypt passwords = yes`. Po przestawieniu również systemów klienckich migracja z haseł szyfrowanych na nie szyfrowane zajdzie dzięki temu płynie.

Metody kodowania (autentyfikacji)

Jak wspomniano wcześniej hasła mogą być szyfrowane i żeby nie było za łatwo istnieje parę metod szyfrowania (nie mylić z dialektami SMB, bo to nie dokładnie to samo):

  • LANMAN (LM): Najprostsza obecnie używana wersja kodowania haseł. Standardowo obsługiwane  przez Windows 95/98/Me/NT 4.0, Windows 2000/XP/2003, Samba 2.x/3.x.
  • NT1(NTLM): Bardziej skomplikowana wersja kodowania haseł. Standardowo obsługiwane  przez Windows NT/2000/XP, Samba 2.x/3.x oraz po zainstalowaniu "Active Directory Client Extensions for Windows 95/98 and Windows NT 4.0" czyli dsclient również obsługiwane przez Windows 95/98/Me/NT 4.0.
  • NT2 (NTLM2): Wersja oparta o szyfrowanie Keyboards. Standardowo obsługiwane  przez Windows 2000/XP/2003 oraz Samba 3.x oraz po zainstalowaniu "Active Directory Client Extensions for Windows 95/98 and Windows NT 4.0" czyli dsclient również obsługiwane przez Windows 95/98/Me/NT 4.0.

Najwcześniejsza wersja kodowania haseł LM jest najbardziej podatna na złamanie przez różne programy, w NTLM poprawiono już znacznie metodę szyfrowania ale najbezpieczniejsze jest używanie NTLMv2. Żeby poszczególne systemy mogły się ze sobą dogadać wysyłają one standardowo wywołania haseł zakodowane przez wszystkie sobie znane metody kodowania. Jak łatwo się domyślić nie jest bezpieczne ale zapewnia wsteczną kompatybilność. Czyli dla przykładu Windows NT nawet żeby porozumieć się z Samba 2.x wyśle hasła zakodowane przez LM jak i NTLM, a przecież wystarczyłoby tylko NTLM.

Na szczęście wszystkie te systemy pozwalają na ustawienie jakiego maja używać kodowania haseł. Dodatkowo można systemy Windows 95/98/ME/NT 4.0 "nauczyć" kodowania NTLMv2, pakiet Samba obsługuje NTLMv2 od wersji 3.0.

Zmiana sposobu autentyfikacji w Windows 95/98/Me:

Żeby mieć dostęp do kodowania NTLM i NTLMv2, poza standardowym LM, powinniśmy wpierw zaktualizować system poprzez instalacje "Active Directory Client Extensions for Windows 95/98 and Windows NT 4.0" czyli dsclient. Zawarty jest on na płycie Windows 2000 Server w katalogu clients\win9x\dsclient.exe, alternatywna metodą zdobycia jego jest pobranie ze stron Microsoft: http://www.microsoft.com/ntworkstation/downloads/Other/adclient.asp. Wymagania dsclient to Windows 95/98/ME lub NT 4.0 z Service Pack 6a oraz minimum Internet Explorer 4.01. O innych możliwościach wprowadzanych przez dsclient przeczytaj na stronie Logowanie do Domeny - opis dla Windows 95/98/Me.

Po instalacji dsclient, pozostało nam pogrzebać w rejestrze.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LMCompatibilityLevel

LMCompatibilityLevel jest wartością DWORD przyjmującą wartość 0 lub 3, gdzie:

  • 0 - system wysyła hasła NTLM oraz LM, bez opcji NTLMv2 (domyślnie)

  • 3 - używane jest tylko NTLMv2

Dokładnie jest to opisane w bazie wiedzy Microsoft pod numerem 239869 - How to Enable NTLM 2 Authentication.

Zmiana sposobu autentyfikacji w Windows NT 4.0:

Żeby mieć dostęp do kodowania NTLM i NTLMv2, poza standardowym LM, powinniśmy wpierw zaktualizować system poprzez instalacje "Active Directory Client Extensions for Windows 95/98 and Windows NT 4.0" czyli dsclient. Zawarty jest on na płycie Windows 2000 Server w katalogu clients\win9x\dsclient.exe, alternatywna metodą zdobycia jego jest pobranie ze stron Microsoft: http://www.microsoft.com/ntworkstation/downloads/Other/adclient.asp. Wymagania dsclient to Windows 95/98/ME lub NT 4.0 z Service Pack 6a oraz minimum Internet Explorer 4.01. Bez dsclient możliwe jest tez osiągniecie zmiany sposobu autentyfikacji w Windows NT 4.0 od Service Pack 4.

Po instalacji dsclient, pozostało nam pogrzebać w rejestrze.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LMCompatibilityLevel

LMCompatibilityLevel jest wartością DWORD przyjmującą wartość 0-5, gdzie:

  • 0 - system wysyła hasła NTLM oraz LM, bez opcji NTLMv2 (domyślnie w Windows 2000/XP)

  • 1 - NTLMv2 jest używane jeżeli jest to możliwe

  • 2 - nie jest używane LM, używa tylko NTLM

  • 3 - używane jest tylko NTLMv2

  • 4 - serwer odrzuca zapytania w standardzie LM

  • 5 - serwer przyjmuje zapytania tylko NTLMv2

Dokładnie jest to opisane w bazie wiedzy Microsoft pod numerem 147706 - How to disable LM authentication on Windows NT.

Zmiana sposobu autentyfikacji w Windows 2000/XP/2003:

Zmian sposobu autentyfikacji dokonujemy poprzez rejestr.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LMCompatibilityLevel

LMCompatibilityLevel jest wartością DWORD przyjmującą wartość 0-5, gdzie:

  • 0 - system wysyła hasła NTLM oraz LM, bez opcji NTLMv2 (domyślnie w Windows 2000/XP) >> WinXP_LM_0.reg

  • 1 - NTLMv2 jest używane jeżeli jest to możliwe

  • 2 - nie jest używane LM, używa tylko NTLM (domyślnie w Windows 2003) >> WinXP_LM_2.reg

  • 3 - używane jest tylko NTLMv2

  • 4 - serwer odrzuca zapytania w standardzie LM

  • 5 - serwer przyjmuje zapytania tylko NTLMv2

Możliwa jest też zmiana poprzez "Panel sterowania" -> "Narzędzia administracyjne" -> "Zasady zabezpieczeń lokalnych" -> "Ustawienia zabezpieczeń" -> "Zasady lokalne" -> "Opcje zabezpieczeń" -> "Zabezpieczenia sieci: poziom uwierzytelniania LAN Manager". Tutaj wystarczy wybrać odpowiednią opcje.

UWAGA: W Windows 2000/XP domyślnie jest ustawione "Wyślij odpowiedzi typu LM i NTLM", dzięki temu nie ma problemu ze współpracą z Windows 95/98/Me, ale kosztem bezpieczeństwa (LM jest łatwiejsze to złamania). Natomiast w Windows Server 2003 domyślnie jest ustawione "Wyślij tylko odpowiedź NTLM" co od razu uniemożliwi współprace z Windows 95/98/Me. Oczywiście wszystkie te opcje można zmienić.

Zmiana sposobu autentyfikacji w Samba/Unix:

W pakiecie Samba zmian dokonujemy poprzez plik konfiguracyjny smb.conf. Domyślnie Samba 2.x rozgłasza autentyfikuje hasła kodowane poprzez LM i NTLM (NTLMv2 dostępne jest w Samba 3.x). Należy jeszcze rozróżnić serwer Samby czyli usługę służącą do udostępniania i uwierzytelniania oraz klienta SMB tutaj jest to smbclient. Owe rozróżnienie trzeba mieć na uwadze gdyż od Samby 3.0 odpowiadają za obie części oddzielne opcje pliku konfiguracyjnego, a dokładnie zostały wprowadzone oddzielne opcje dla klienta czyli smbclient. Jeśli używasz wcześniejszej samby czyli np. 2.0 lub 2.2 masz do dyspozycji tylko opcje lanman auth dotycząca w tym wypadku zarówno serwer samby jak i smbclient.

W serwerze Samby, żeby wyłączyć autentyfikacje haseł kodowanych LM i uwierzytelniać tylko poprzez NTLM, zmień opcje globalną lanman auth w smb.conf. Dopuszczalne wartości:

  • lanman auth = yes (domyślnie) - serwer Samby wysyła hasła NTLM oraz LM, bez opcji NTLMv2

  • lanman auth = no - serwer Samby nie używa LM, używa tylko NTLM

Dodatkowe opcje dostępne od Samba 3.0 w serwerze Samby:

  • ntlm auth = yes (domyślnie) - serwer Samby wysyła hasła NTLM oraz LM, bez opcji NTLMv2, chyba że jest ustawione dodatkowo lanman auth = no, wtedy system wyśle NTLM i NTLMv2.

  • ntlm auth = no - serwer Samby nie używa NTLM, jeśli dodatkowo ustawione jest lanman auth = no, wtedy serwer Samby używa tylko NTLMv2.

Jeśli chcesz zmienić opcje autentyfikacji tylko klienta Samby czyli smbclient łączącego się ze zdalnymi serwerami użyj opcji dostępnych od Samby 3.0:

  • client lanman auth  = yes (domyślnie) - smbclient łącząc się będzie wysyłał hasła LM.

  • client lanman auth  = no - smbclient łącząc się nie będzie wysyłał haseł LM, ale tylko NTLM lub/i NTLMv2 czyli będziesz mógł się połączyć z Samby tylko na serwery typu Windows NT ale nie juz Windows 9x. W tym wypadku będzie ustawione client plaintext auth = no.

  • client ntlmv2 auth = no   (domyślnie) - smbclient łącząc się nie będzie wysyłał hasła NTLMv2.

  • client ntlmv2 auth = yes   - smbclient łącząc się będzie wysyłał tylko hasła NTLMv2, gdyż ustawione będą opcje. client lanman auth  = no oraz client plaintext auth = no. Wynika z tego że będziesz mógł się połączyć z Samby tylko na serwery typu Windows NT od NT 4.0 SP4 ale nie juz Windows 9x oraz samba 2.2.

  • client plaintext auth = yes (domyślnie) - smbclient łącząc się będzie wysyłał hasła niekodowane jeśli serwer nie obsługuje haseł kodowanych.

  • client plaintext auth = no - smbclient łącząc się nie będzie wysyłał haseł niekodowanych.

RestrictAnonymous - Ograniczenie anonimowego dostępu

W systemach z rodziny Windows NT oraz Samba/Unix standardowa instalacja pozwala anonimowemu użytkownikowi przeglądanie na tych systemach zarówno udostępnionych zasobów jak i sprawdzenie listy kont w systemie. Anonimowy użytkownik to taki który nie posiada konta na maszynie którą odpytuje tudzież w domenie jeśli maszyna jest podłączona do domeny. Sytuacja ta stanowi oczywiście lukę w zabezpieczeniach gdyż anonimowy użytkownik może się sporo dowiedzieć na temat naszego systemu a przecież lista kont to już spora wiedza którą nie zawsze chcielibyśmy się chwalić.

Można oczywiście owej sytuacji zapobiec czyli ograniczyć anonimowy dostęp poprzez tzw. RestrictAnonymous ale należy z tego korzystać ostrożnie i przemyślnie gdyż spowoduje to ograniczenia w dostępie dla starszych klientów sieci SMB . O opcji RestrictAnonymous możesz poczytać w bazy wiedzy Microsoft pod numerem 143474 - Restricting information available to anonymous logon users oraz 246261 - Jak używać wartości rejestru RestrictAnonymous w systemie Windows 2000.

Windows NT 4.0

Opcja RestrictAnonymous w systemie Windows NT 4.0 działa od Service Pack 3 i aby ją uaktywnić przejdź do podanego klucza w rejestrze.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

Należy stworzyć tutaj wartość DWORD o nazwie RestrictAnonymous i możemy jej nadać wartości 0 lub 1:

  • 0 - Zezwolenie na anonimowe odpytywanie czyli polegaj na zezwoleniach domyślnych

  • 1 - Ograniczenie anonimowego odpytywania czyli nie zezwala na wyliczanie kont i udziałów SAM

Windows NT 2000/XP/2003

Opcja RestrictAnonymous w systemach Windows 2000/XP/2003 dostępna jest standardowo oraz dodano dodatkowo jeszcze jedna opcję. Aby ją uaktywnić przejdź do podanego klucza w rejestrze.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

Należy stworzyć tutaj wartość DWORD o nazwie RestrictAnonymous i możemy jej nadać wartości 0, 1 bądź 2:

  • 0 - Zezwolenie na anonimowe odpytywanie czyli polegaj na zezwoleniach domyślnych

  • 1 - Ograniczenie anonimowego odpytywania czyli nie zezwala na wyliczanie kont i udziałów SAM
    UWAGA: W systemach Windows 2000/XP/2003 wartość 1 nie chroni całkowicie przed anonimowym dostępem, dalej możliwe jest uzyskanie anonimowego dostępu poprzez port 445 czyli usługi katalogowe. Dlatego też powstała opcja 2.

  • 2 - Brak dostępu bez wyraźnych zezwoleń anonimowych
    UWAGA: Ustawienie opcji RestrictAnonymous na 2 spowoduje brak możliwości dostępu dla starszych klientów SMB takich jak Windows 95/98/ME/NT 4.0 oraz ewentualnie problemy z różnym oprogramowaniem które korzystało z anonimowego dostępu. Dlatego też używaj tej opcji ostrożnie.

Samba/Unix

Opcja RestrictAnonymous w systemach Samba/Unix jest ustawiania w pliku konfiguracyjnym Samby czyli smb.conf w sekcji [global]. Aby korzystać z RestrictAnonymous należy dodać opcje:

restrict anonymous

Może ona przybierać wartości  0, 1 bądź 2 które są dokładnym odzwierciedleniem tych z systemów Windows 2000/XP/2003 czyli:

  • 0 - Zezwolenie na anonimowe odpytywanie czyli polegaj na zezwoleniach domyślnych

  • 1 - Ograniczenie anonimowego odpytywania czyli nie zezwala na wyliczanie kont i udziałów SAM

  • 2 - Brak dostępu bez wyraźnych zezwoleń anonimowych
    UWAGA: Ustawienie opcji RestrictAnonymous na 2 spowoduje brak możliwości dostępu dla starszych klientów SMB takich jak Windows 95/98/ME/NT 4.0 oraz ewentualnie problemy z różnym oprogramowaniem które korzystało z anonimowego dostępu. Dlatego też używaj tej opcji ostrożnie.



Drukuj Dokument