Powyżej wersji 0.60 klient SSH PuTTY posiada wsparcie dla tzw. agenta uwierzytelniania. Dołączona do programu wersja – Pageant – pozwala na załadowanie do pamięci wielu kluczy i uwierzytelnianie nimi nie tylko połączeń z lokalnego komputera, ale w przypadku połączeń przez serwery OpenSSH również kolejnych sesji (agent forwarding).
KeeAgent – plugin do KeePass \”podszywający się\” pod Pageanta pozwala na przechowywanie kluczy SSH w rekordach bazy kdbx programu KeePass.
Aby dodać plugin do menadżera kluczy, z pobranego ze strony projektu archiwum kopiujemy plik KeeAgent.plgx do katalogu instalacji. Przy ponownym uruchomieniu, zostanie on skompilowany i załadowany.
Pliki kluczy SSH (ppk) dodajemy do rekordów w \”zaawansowanych\” jako załączniki. Jeżeli są zabezpieczone hasłem – podajemy je jako hasło we wpisie.
Następnie przechodzimy do konfiguracji PuTTY.
Wybierając opcję \”Attempt authentication using Pageant\” zapewniamy sobie możliwość logowania kluczem z odblokowanej bazy KeePass z komputera lokalnego.
Opcja \”Allow agent forwarding\” pozwala na użycie Pageanta w uwierzytelnianiu kolejnych połączeń z serwera do którego jesteśmy zalogowani. Nie powinno się używać tej opcji na serwerach, którym nie ufamy – klucze mogą zostać użyte wtedy również przez administratora systemu (podobnie jak hasło, które wpisywaliśmy jak dotąd).
Po właściwej konfiguracji, po połączeniu do serwera który rozpoznaje nasz klucz powinno ukazać nam się powiadomienie jak i gotowa do pracy sesja zdalnej konsoli.
Nowy pracownik naszej firmy, administrator Linux Mateusz Małek, w ramach prowadzonych testów podatności przeprowadził udany, a zarazem trywialny atak mający wpływ na stabilność pracy jednego z naszych serwerów hostingowych.
Poniżej prezentujemy sposób częściowy zabezpieczenia serwera przed lokalnymi atakami DoS wykonywanymi przy pomocy funkcji shell_exec() w PHP, jeżeli wykorzystywany jest suPHP.
W przypadku wykorzystywania suPHP, uruchamiane z UID+GID użytkownika procesy nie przechodzą przez stos PAM, tym samym nie dotyczą ich limity pam_limits.so z /etc/security/limits.conf. Opisane poniżej kroki zmieniają to zachowanie.
Patchowanie, rekompilacja i rekonfiguracja suPHP
Nakładamy przygotowany patch na suPHP:
cd /usr/local/directadmin/custombuild
cp $(find -type d -name \’suphp-0*\') suphp-patched;
cd suphp-patched;
wget http://mkwm.zielonki.info/suphp_patch.diff -O – | patch -p1
Tworzymy nową usługę PAM – np. \”suphp\”, uwzględniającą moduł pam_limits z dedykowaną konfiguracją – wykorzystanie globalnego pliku konfiguracyjnego stwarza pewne problemy (o czym za chwilę):
Konfigurujemy limity dotyczące liczby procesów (tak, serwer uległ \”trzynastu znakom\”). Dedykowany plik konfiguracyjny rozwiązuje problem z sytuacją, w której konta użytkowników nie posiadają żadnej wspólnej grupy – w przypadku ustawienia limitów dla wszystkich (*), nie ma możliwości podniesienia ich dla konkretnego użytkownika/grupy (co powoduje problemy z działaniem usług czy administrowaniem serwerem):
Debian Linux jest systemem operacyjnym. To potężne narzędzie, które może przynosić wiele korzyści w sieci. Używanie go w środowisku Windows może być bardzo trudne. Jest tam wiele przeszkód, które nie pozwalają na gładkie wprowadzenie systemu Debian Linux w sieci. Pierwszą rzeczą, i bardzo ważną, jest wprowadzenie autentyczności dla konta użytkownika.
Jeśli stacje robocze są w domenie Active Directory (AD), użytkownicy używają potwierdzenia autentyczności. Gdy nazwa użytkownika i hasło są używanie dla jednej lub drugiej usługi może to stwarzać dużo problemów. Jeśli kiedykolwiek czytelnik próbował postawić system Debian Linux w produkcji, prawdopodobnie napotkał ten problem. Dodatkowo, w środowisko AD, administratorzy mogą logować się do jakiejkolwiek maszyny i rozwiązywać problemy wykorzystując hasło administratora domeny.
Co mamy do tej pory to: aktywna nazwa użytkownika i hasło do bazy danych, które jest ciągle wykorzystywane do potwierdzenia autentyczności w usługach sieciowych. To luksusy, które powinny wyznaczać drogę jaką trzeba podążać. Jeśli nie można ustalić autentyczności użytkowników do domeny AD, wtedy usługi udostępniane na zewnątrz są niepewne i należy stworzyć oraz uaktualnić bazę danych użytkowników.
Potwierdzenie autentyczności AD nie należy do działania Debian’a, więc jest potrzebne jakieś oprogramowanie, które musi być użyte do zezwolenia na współpracę między dwoma programami. Oprogramowanie, które to umożliwia jest nazywane Sambą. Zajmuje się ona udostępnianiem plików i innych cech sieci, co jest charakterystyczne dla komputerów z systemem Windows. Winbind jest składnikiem Samby, który odwzorowuje (mapping) użytkownika i grupy z Active Directory do języka Linux. Kerberos jest nisko-poziomowym protokołem używanym do potwierdzenia autentyczności hasła w sieci, gdzie jest używana nieszyfrowana transmisja z sesją AD.
Instrukcja ta pokaże jak zainstalować udostępniany folder używając do tego systemu Debian z linuxowy serwerem plików. Można przypuszczać, że wystarczy skorzystać z prawa jakie ma konto root. Te parę kroków jest konieczne do wykorzystania potencjału systemu Debian w AD. W skrócie zostanie to przedstawione poniżej.
Instalowanie niezbędnych paczek używanych przez Debian w środowisku Active Directory
Paczki te są potrzebne do zainstalowania prostego serwera plików Samba używanego przez Debian Lenny i przy autentyfikacji w środowisku AD. Instalujemy Sambę oraz Kerberos’s następującym poleceniem:
Niestety w repozytoriach do Lennego, nie znajdziemy odpowiedniej wersji Samby, dlatego skorzystamy z backportów.
Dodajemy do pliku etc/apt/sources.list wpis:
uruchamiamy apt-get update i importujemy klucze do repozytorium:
Wstawiamy w Workgroup/domena informacje kiedy ma być wprowadzony. Zostanie zainstalowany jakiś plik .conf do wykorzystania. W tej chwili nie będziemy się martwić o serwer WINS. Gdy proces zostanie zakończony Daemons automatycznie się uruchomi. Potrzebujemy zastopować działąnie tego pliku podczas jego konfiguracji. Żeby zatrzymać działanie Samby oraz Winbind wpisujemy:
Tworzenie pliku konfiguracyjnego używanego przez Debian w środowisku AD
Wszystkie pliki konfiguracyjne znajdują się w folderze /etc/samba. Warto jest przeczytać je i w celu stworzenia odpowiedniej wiedzy – modyfikować (po uprzednim skopiowaniu oryginalnych plików!).
tworząc własny plik /etc/samba/smb.conf dobrze jest upewnić się czy domena jest zgodna
Konfiguracja i testowanie Kerberos przy użyciu Debian w środowisku AD
Ponieważ Samba już wie jaką jest częścią domeny mamy podstawową jej konfigurację. Potrzebujemy teraz autentykacji jej pracy. Kerberos jest oprogramowaniem, które łączy się z domeną AD w celu autentykacji użytkowników. Bardzo ważne jest to, żeby czas na serwerze był zsynchronizowany z kontrolerem domeny AD.
Edytujemy plik konfiguracyjny Kerberos w celu prawidłowego określenia kontrolera domeny.
ważna część to konfiguracja domeny /etc/krb5.conf :
Można testować możliwości Kerberosa sprawdzając hasło użytkownika przez wpisanie:
następnie typ:
Jeżeli efekt końcowy wygląda tak jak poniżej, wszystko jest gotowe.
Numerowanie kont w AD w Linuksie poprzez Winbind używając Debian w środowisku AD
Do numerowania użytkowników w AD najpierw trzeba dokonać aktualizacji pliku nsswitch.conf:
dodajemy “winbind” do passwd i w linii grupy. Jeżeli posiadamy “compat” w lini, można zrobić coś takiego:
Przyłączenie serwera Debian Linux do AD – użycie Debian w środowisku AD
Gdy już wszystko mamy skonfigurowane uruchamiamy Sambe i Winbind:
Jeżeli wszystkie pozostałe kroki zostały poprawnie wykonane, można teraz bez problemu przyłączyć komputer do domeny. Dla komputera tworzymy konto w AD.
powinniśmy zobaczyć:
Możemy przetestować Winbind oraz poprawność jego działania wpisując:
Autoryzacja Winbind w celu autentykacji użytkowników na serwerze – użycie Debian w środowisku AD
Pozwoli to na logowanie do hosta na konta AD. Należy edytować następujące pliki, które powinny wyglądać tak:
Bardzo ważne jest to, żeby w “obey pam restriction” było ustawione „yes” (w pliku smb.conf), żeby powyższe ustawienia były efektywne.
Nadawanie dostępu administracyjnego w AD w Debian Linux Server
Polecenie sudo pozwala administratorowi systemu dopasować autentykacje dla grupy lub użytkownika do nadania odpowiednich możliwości działania. Przypuścimy, że mamy domenę zabezpieczonej grupy nazwanej ‘TCP’. Następujące polecenie nada grupie w AD odpowiednie prawa i dostęp:
przesuniemy do samego końca i dodamy linie:
Po wykonaniu tego polecenia grupa ‘TCP’ pełny dostęp do serwera co z wiadomych względów nie jest bezpieczne.
Tworzenie grupy udostępniającej w domenie grupy przy użyciu Samby – użycie Debian w środowisku AD
Jak tylko dołączyłeś do serwera Samby w swojej domenie i po wywołaniu identyfikacji użytkownika – tworzenie udostępniania i dostępu grupy do plików jest proste. Musimy stworzyć folder, który jest własnością root’a i domeny grupy. Samba odziedziczy dostęp po folderze nadrzędnym. Przykład dla stwarzania folderu w domenie grupy nazwijmy „corporate_HR ”. Domena jest zatytułowana “ acme ”. Tam jest administracyjna grupa wsparcia “ admins”. Ustawiając dostęp do folderu na ‘2771’ powoduje, że Root i grupa „corporete HR” ma pełen dostęp. To zmusi wszystkie nowe pliki utworzone pod folderem HR do wzięcia parametru grupowego z tej rodziny. Używając parametru “force group ” należy upewnić się, że pozwolenia są odpowiednio dobrane i członek z grupy „ACME\\admins ” ma dostęp do plików.