| Siec TCP/IP || Otoczenie Sieciowe || Poczta || Usnet || FTP || Konto Shellowe || Czat || IRC || Serwer PROXY |
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ć.
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ą.
Pliki te modyfikują jedną wartość w gałęzi rejestru.
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):
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:
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:
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:
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) >> 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:
Dodatkowe opcje dostępne od Samba 3.0 w serwerze Samby:
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:
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:
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:
2 - Brak dostępu bez wyraźnych
zezwoleń anonimowych 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:
|