L

ogin jest programem, który nawiązuje nowe sesję z systemem w celu dopuszczenia użytkownika do jego konta shell. Stan gotowości tego programu możemy rozpoznać po znaku zachęty “login: ” wyświetlanym na naszym aktualnym terminalu. Wtedy jesteśmy w stanie podać nasz login oraz po pojawieniu się znaku zachęty “Password: ” nasze hasło (w trakcie wpisywania hasła opcja ukazywania – echo jest wyłączona lub ukazywane są znaki “*” – w zależności od konfiguracji systemu).

     Po podaniu poprawnych danych zostaniemy dopuszczeni do naszego konta shell – czyli z pliku /etc/passwd zostaną odczytane informacje o powłoce systemowej jaka nam przysługuje, a następnie zostaniemy przeniesieni do naszego macierzystego katalogu – dokładna data oraz skąd podjęliśmy łączność z systemem zostanie zapisana do pliku “utmp” (listy aktualnie aktywnych sesji – listę tych sesji możemy wyświetlić przy pomocy polecenia ‘who’, ‘users’ lub ‘finger’ – w zależności jak dokładne informacje chcemy otrzymać) i “wtmp” (listy poprzednich sesji – listę tych sesji możemy wyświetlić przy pomocy polecenia ‘last’) – położenie tych plików zależy od konfiguracji systemu jednak zazwyczaj są to: /var/run/utmp oraz /var/log/wtmp. Zasady według, których wyżej wymienione czynności będą przebiegały możemy określić poprzez wprowadzenie odpowiednich wartości do plików /etc/login.defs oraz /etc/login.access. Pierwszy jak i drugi plik jest konfiguracyjnym plikiem kontrolnym dla pakietu login. W pliku login.defs możemy określić między innymi takie wartości jak: minimalną długość hasła, czas pomiędzy wyświetlaniem się kolejnych znaków zachęty “login: “, czy ilość nieudanych prób logowania się do systemu. Natomiast w pliku login.access możemy określić kto może mieć prawo logowania się z konsoli serwera jak i lokalnego lub zdalnego hostu. Plik login.defs składa się z wielu wierszy gdzie każdy z nich dotyczy jednego z parametrów konfiguracji (oprócz wierszy opatrzonych na początku znakiem komentarza “#”), dlatego kolejnym krokiem do prostej konfiguracji bezpieczeństwa jest edycja tego pliku oraz ustawienie lub przestawienie paru ustawień, które umożliwią nam kontrolowanie zasad logowania się przez użytkowników:

• FAIL_DELAY 7 – zmienna ta powinna posiadać zdecydowanie większą wartość niż 3 ze względu na to, że odpowiada ona za czas pomiędzy wyświetlaniem następnego znaku zachęty “login: ” po nieudanej autoryzacji i tym samym daniu następnej możliwości zalogowania. Dzięki temu możemy utrudnić włamanie za pomocą metody brute force przy użyciu terminala. W naszym przypadku pojawienie się nowego promptu “login: ” od popełnienia błędu zajmie siedem sekund. Dodatkowo użytkownicy nauczą się poprawnego i szybkiego wpisywania loginów oraz haseł.
• FAILLOOG_ENAB yes – jeśli włączymy tę opcję (należy się liczyć z wielkością partycji /var gdzie standardowo przetrzymywane są logi systemowe), każde nieudane logowanie będzie zapisywane do pliku dziennika /var/log/faillog. Dzięki tej opcji jesteśmy w stanie śledzić czy ktoś niepowołany próbuje się dostać na nasze konto lub konto jakiegoś przypadkowo wybranego użytkownika. Oczywiście może się zdarzyć, że użytkownik, który zapomniał hasła będzie wiele razy próbował potwierdzić swoje przypuszczenia, co do jego autentyczności, dlatego to użytkownicy powinni powiadamiać administratorów o podejrzanych próbach logowania.
• LASTLOG_ENAB yes – oprócz plików logujących jak wtmp oraz utmp możemy także uaktywnić dodatkowy plik /var/lastlog, w którym także będą zapisywane informacje na temat ostatnich logowań do systemu wszystkich użytkowników zapisanych do pliku z hasłami /etc/passwd. Dzięki komendzie ‘lastlog’ możemy wyświetlić listę wszystkich użytkowników mających wpis w wyżej wymienionym pliku oraz uzyskać informacje na temat ich ostatniego logowania (port połączenia, miejsce skąd się łączyli z naszym serwerem oraz ostatnią date logowania).
• SYSLOG_SU_ENAB yes – opcja ta powoduje, że wszystkie logowania na konto root za pomocą programu ‘su’ będą zapisywane do pliku dziennika /var/log/secure. Opcja ta jest bardzo przydatna, gdy na maszynie jest dwóch lub więcej administratorów. Może się także zdarzyć, że jakiś użytkownik pozna nasze hasło i wykorzysta program ‘su’ do sprawdzenia jego autentyczności.
• SYSLOG_SG_ENAB yes – opcja działająca tak samo jak SYSLOG_SU_ENAB tylko z tą różnicą, że odwołuje się do polecenia ‘sg’ (zmiana aktualnej grupy). Jeśli mamy taką potrzebę możemy też uaktywnić opcję SULOG_FILE, która określi także inny plik niż /var/log/secure do zapisywania aktywności związanej z programem ‘su’ i ‘sg’ – standardowo będzie to plik /var/log/sulog.
• PASS_MAX_DAYS 120 – opcja określająca, co ile dni hasło powinno być zmieniane. Wartość 99999 powoduje, że raz ustawione hasło będzie mogło być wykorzystywane zawsze, ale nawet najlepsze hasło może być po jakimś czasie podpatrzone czy przez przypadek odgadnięte – dlatego powinniśmy zmusić użytkowników do systematycznej jego zmiany. Ustawienie wartości 120 spowoduje, że każdy użytkownik będzie zmuszony do zmiany hasła średnio, co cztery miesiące. Tutaj należy wspomnieć, że okres ważności hasła nie może być za krótki. Jeżeli okres ważności hasła jest zbyt krótki, użytkownicy naszego systemu będą mogli mieć obawy, że zapomną swoje hasła i zaczną je zapisywać lub nawet zaczną korzystać z cyklicznych, łatwych haseł.
• PASS_MIN_DAYS 0 – opcja określająca, co ile dni użytkownik posiada możliwość zmiany hasła. Najlepiej jeśli pozostawimy jej standardowe ustawienie czyli ‘0’ dlatego, że w razie nagłej potrzeby zmiany hasła przez danego użytkownika np. z powodu uznania, że jest ono za słabe nie będzie on posiadał takiej możliwości.
• PASS_MIN_LEN 9 – czyli minimalna długość ciągu hasła, wiadomo im większa liczba znaków w haśle tym trudniejsze jest ono do złamania oraz w niektórych przypadkach do zapamiętania.
• PASS_WARN_AGE 7 – ilość dni przed końcem wygaśnięcia naszego hasła, w których będziemy ostrzeżeni o zbliżającym się terminie – czyli tydzień przed wygaśnięciem naszego hasła system powiadomi nas o tym.
• SU_WHEEL_ONLY yes – jeśli uaktywnimy tą opcję to jedynie użytkownik, czy użytkownicy dopisani do pierwszej grupy w pliku /etc/group o identyfikatorze 0 (root) będą w stanie uruchomić program ‘su’ i tym samym uzyskać prawa administratora. Jest to dobrym zabezpieczeniem przed ewentualnym uniknięciem uzyskiwania nieuprawnionych przywilejów przez niewytypowanych przez nas użytkowników.
• LOGIN_RETRIES 3 – ilość kolejnych dopuszczalnych prób po nieudanym logowaniu. Wartość ta nie powinna przekroczyć 3, ze względu na powiązanie z funkcją FAIL_DELAY. Jeśli przedłużymy czas odstępu oraz ograniczymy ilość prób, tym mniejsze szanse na powodzenie ataku metodą brute force.
• PASS_CHANGE_TRIES 3 – trzy próby zmiany hasła to chyba wystarczająca ilość szans na możliwość pomylenia się podczas wpisywania starego hasła, czy ponownej weryfikacji nowego.
• CHFN_AUTH yes – podczas dodawania nowych użytkowników możemy określić dodatkowe informacje na ich temat np. pełne imię i nazwisko, numer pokoju, telefon do pracy i domu itp. Zwykli użytkownicy także mogą to zrobić poprzez wydanie komendy ‘chfn’. Ustawiając tą opcję na yes da nam rezultat w postaci, że przed możliwością dokonania jakichkolwiek zmian w tych polach użytkownik zostanie poproszony o podanie własnego hasła (taki sam rezultat będzie dla komendy ‘chsh’ – która umożliwia zmianę powłoki).
• CHFN_RESTRICT h – jeśli chcemy, aby użytkownicy nie posiadali możliwości zmiany swoich danych osobowych bez naszej wiedzy wystarczy, że zaraz po funkcji CHFN_RESTRICT skasujemy wartość ‘frwh’ pozostawiając puste pole. Lub możemy też ograniczyć wprowadzanie zmian do domowego telefonu, czyli pozostawiając z ‘frwh’ tylko ‘h’ (gdzie f – to pełne imię i nazwisko, r – numer pokoju, w – telefon do pracy, h – telefon domowy).
• MD5_CRYPT_ENAB yes – jeśli włączymy tę funkcję – od tego momentu hasła systemowe będą kodowane za pomocą algorytmu MD5 kompatybilnym z tym, który używany jest w systemie FreeBSD. Obsługuję on “nielimitowane” ciągi haseł. Schemat kodowania MD5 jest bardzo przydatny przy tworzeniu mocnych oraz długich haseł, które bardzo trudno złamać (szczególnie metodą słownikową) lub potrzeba do tego bardzo dużej ilości czasu. Więcej informacji na temat szyfrowanie MD5 możemy znaleźć w dokumencie RFC1321.
• DEFAULT_HOME no – opcja “no” nie pozwala się zalogować użytkownikom, którzy z jakiegoś powodu nie posiadają prawa dostępu do swojego macierzystego katalogu. Opcja ta jest bardzo przydatna jeśli chcemy szybko uniemożliwić dostępu do systemu danemu użytkownikowi.
• GETPASS_ASTERISKS 7 – podczas wpisywania hasła standardowo żadne znaki nie ukazują się na monitorze. Opcja ta pozwala użyć funkcji getpass(), która losowo będzie wyświetlała od 1 do 7 znaków w postaci gwiazdki (*) na każdy wpisany przez nas znak. Czyli opcja z wartością -1 spowoduje standardowe zachowanie pod postacią żadnych znaków, 1 – jedna gwiazdka za jeden znak oraz większe wartości – poprzez losowy wybór. Funkcja ta jest dedykowana dla osób, które próbują liczyć długość naszego hasła, lub spoglądają przez ramię w celu jego odgadnięcia. Wprowadzenie dużej ilości gwiazdek pod postacią ukrytych znaków powinno zamieszać trochę w ich zamiarach. Jednak mimo gwiezdnej ochrony należy upewnić się, co do poufności przy wprowadzaniu haseł z klawiatury.

Jeśli chodzi o plik login.access to posiada on trochę inną budowę. W pliku tym tworzymy reguły złożone z trzech pól, które określają kto i skąd może uzyskać dostęp do systemu. Poszczególne pola są oddzielone znakiem dwukropka “:” (rodzaj dostępu : użytkownik lub użytkownicy : adres lub adresy). W pierwszym polu definiujemy rodzaj dostępu. Poprzez umieszczenie plusa “+” – nadajemy prawo dostępu, oraz minusa “-” – nadając brak dostępu. W drugim polu możemy umieścić nazwy loginów lub grup. Lub po prostu umieścić wpis “ALL” tyczący się wszystkich systemowych jak i poza systemowych użytkowników. Trzecie pole powinno zawierać listę nazw jednego lub więcej terminali (dla zdefiniowania praw dostępu z konsoli), hostów, domen (zaczynających się od kropki “.”). Jeśli użyjemy wartości “ALL” będzie się ona tyczyła wszystkich adresów sieciowych jak i terminali. W celu tworzenia bardziej zwartych reguł możemy zastosować operator “EXCEPT“. Przypuśćmy, że chcemy całkowicie ograniczyć logowania innych użytkowników z lokalnych konsoli serwera oprócz administratora oraz użytkownika, który posiada prawa by uzyskać status administratora (agresor). W tym celu do pliku login.access dodajemy następującą regułę:

-:ALL EXCEPT root agresor:tty1 tty2 tty3 tty4 tty5 tty6

Przeanalizujmy powyższy ciąg. Pierwsze pole oznacza dodanie reguły zabraniającej dostępu. Następnie uwzględniamy kto nie ma go posiadać – w naszym przypadku wszyscy (ALL) oprócz (EXCEPT) użytkownika root, czyli administratora oraz użytkownika o loginie agresor. Celem naniesionych restrykcji są aktualnie aktywne, lokalne konsole serwera (tty1 itd.). Tak więc administrator jak i użytkownik agresor jako jedyni posiadają dostęp do konsoli (przed dodaniem wyżej wymienionej reguły należy sprawdzić listę aktywnych konsol). Jak widzimy reguła ta jest dobrą metodą nie pozwalającą na logowanie się nieuprawnionych przez nas użytkowników na lokalnych konsolach serwera. Jeśli chcemy jeszcze bardziej ograniczyć prawa do logowania się przez administratora np. aby posiadał on tylko i wyłącznie możliwość logowania się z lokalnej konsoli, a logowanie z sieci czy lokalnych hostów nie było możliwe – dodatkowo dodajemy następującą regułę:

-:root:ALL EXCEPT tty2 tty5

Wadą tego wpisu jest fakt iż drugie pole tyczy się zarówno użytkowników jak i grup, dlatego na wszystkich użytkowników dopisanych do grupy root zostaną nałożone restrykcje. Jeśli nie posiadamy w systemie takich użytkowników nie mamy się czym przejmować. Lecz jeśli w przyszłości planujemy taką ewentualność dobrze się jest zabezpieczyć na przyszłość. “Błąd” ten możemy ominąć poprzez dodanie nowej grupy do systemu oraz dopisanie do niej administratora czyli użytkownika o loginie “root”. Dla przykładu: dodajemy do naszego systemu nową grupę o nazwie “tty” o identyfikatorze równym 5 (polecenie: groupadd -g 5 tty). Następnie poprzez edycje pliku /etc/group dodajemy do tej grupy konto root (wpis powinien posiadać następującą postać: tty:x:5:root). Oraz zmieniamy powyższy wpis na:

-:tty:ALL EXCEPT tty2 tty5

W ten prosty sposób ograniczamy tylko i wyłącznie grupę “tty” i wszystkich użytkowników do niej należących, czyli w naszym przypadku użytkownika “root” – możliwość logowania do systemu jest akceptowana tylko i wyłącznie z drugiej i piątej lokalnej konsoli serwera. Lecz poprzez dodanie powyższego wpisu naruszyliśmy integralność logowania się superużytkownika do systemu z lokalnej konsoli. Dlatego powyższy wpis powinien być zweryfikowany z listą “bezpiecznych konsol” znajdujących się w pliku /etc/securetty, który także posiada możliwość wprowadzenia ograniczeń w stosunku do lokalnych konsol. Lista “bezpiecznych konsol” (czyli te które nie posiadają znaku komentarza “#” przed sobą) powinna być zgodna z nazwami tych konsol, które zawarliśmy w wyżej wymienionym wpisie.

Więcej informacji: man login, man login.defs, man login.access