Pluggable authentication modules (PAM) - rejestrowanie poczynań użytkowników - pam_tty_audit

Red Hat 6.x / CentOS 6.x

Ciekawym modułem PAM pozwalającym rejestrować poczynania użytkownika w sposób wręcz paranoiczny jest pam_tty_audit.

Moduł konfigurujemy poprzez określenie jako opcji loginu lub loginów użytkowników których chemy śledzić. Działa on jedynie dla typu session, i w taki sposób go skonfigurujemy.

Konfiguracja odbywa się w znanych już plikach /etc/pam.d/system-auth oraz /etc/pam.d/password-auth:

session     optional      pam_keyinit.so revoke
session     required      pam_tty_audit.so enable=test,test2
session     required      pam_limits.so

Przytoczony powyżej przykład spowoduje logowanie działań użytkowników test oraz test2.

Do dyspozycji posiadamy opcje konfiguracyjne:
* enable= - określa oddzielone przecinkiem loginy użytkowników, których chcemy śledzić. Możliwe jest użycie wildcarda * definiującego wszystkich userów w systemie.
* disable= - loginy użytkowników, których śledzić nie chcemy
* log_passwd - standardowo nie są logowane wpisywane przez użytkownika hasła - tą opcją możemy ten stan zmienić

Kolejność wystąpienia opcji enable i disable jest istotna i determinuje zachowanie modułu. Należy pamiętać, że są parsowane w kolejności podania, a każda z nich nadpisuje listę użytkowników z poprzedniej. Inne zatem działanie będzie miała składnia enable=* disable=root logując wszystkich poza rootem, a inne disable=root enable=* logując wszystkich bez wyjątku.

Do przeglądania zalogowanych zdarzeń używać będziemy narzędzia dedykowanego do generowania raportów audytowych z usługi auditd, a mianowicie aureport. Zastosowanie opcji -i powoduje "interpretację" uid usera, czyli jego podmianę na nazwę użytkownika.

[root@server pam.d]# aureport --tty -i

TTY Report
===============================================
# date time event auid term sess comm data
===============================================
1. 10/07/2015 17:26:09 2480 test ? 331 bash <ret>,<ret>,<ret>,"ll",<ret>,"csd /.",<backspace>,<backspace>,<backspace>,<backspace>,<backspace>,"d /tmp",<ret>,"ll",<ret>,"cd o",<tab>,<ret>,"ll",<ret>,<up>,<up>,<tab>,<tab>,"g",<tab>,<ret>,"l",<backspace>,<^D>
2. 10/07/2015 18:46:47 2576 test ? 341 less "q"
3. 10/07/2015 18:46:48 2577 test ? 341 bash "test",<ret>,"man test",<ret>,<^D>
4. 10/07/2015 19:02:43 2699 test ? 348 bash "ll",<ret>,"touch test",<ret>,<^D>
5. 10/07/2015 19:02:57 2725 test2 ? 349 bash "ll",<ret>,"pwd",<ret>,"touch test",<ret>,<^D>

Jak widać na przykładzie logowanie jest bardzo dokładne i w podstawowej opcji obejmuje niciśnięcie przez użytkownika każdego klawisza, jeśli wpisywane znaki nie są częścią hasła.

Pluggable authentication modules (PAM) - blokowanie użytkowników po nieudanej próbie logowania - pam_tally2

Red Hat 6.x / CentOS 6.x

Moduł pam_tally2 to swoisty licznik nieudanych logowań użytkowników do systemu. Działanie to pozwala nam wykrywać próby złamania hasła usera i włamania na serwer. Poza monitorowaniem prób pam_tally2 pozwala nam również proaktywnie na nie odpowiadać np. poprzez blokowanie konta użytkownika dla którego wykryto zbyt dużą ilość nieudanych prób autoryzacji.

Uruchomienie procesu monitorowania logowań

Jak w przypadku wszystkich modułów pam, uruchomienie i tego wymagać będzie dodania go do odpowiedniej sekcji konfiguracji. Jako, że moduł ma nadzorować próby autoryzacji (typ auth) będzie on koniecznym (required) elementem konfiguracji dla wszelkich aplikacji dokonujących autoryzacji użytkownika w systemie, więc dodany musi zostać w plikach /etc/pam.d/system-auth oraz /etc/pam.d/password-auth. Słowem wyjaśnienia password-auth odpowiada za procesy autoryzacyjne przy zdalnym dostępie do systemu (np. ssh), system-auth natomiast za dostęp bezpośredni (np. konsola serwera).

Moduł powinien być uruchamiany przed zautoryzowaniem użytkownika, dlatego wpis należy umieścić przed modułem pam_unix, który jako sufficient po zautoryzowaniu użytkownika nie dopuści do weryfikacji modułów występujących po nim. Dodana linia wyglądać będzie następująco:

auth        required      pam_env.so
auth        required      pam_tally2.so [opcje]
auth        sufficient    pam_unix.so nullok try_first_pass

Opcje modułu

Pełną listę opcji znajdziemy oczywiście w manualu modułu. Najprzydatniejsze w moim wypadku okazały się:

* deny=N, która zablokuje dostęp do konta po N nieudanych próbach logowania. Jeśli w konfiguracji nie zdefiniowaliśmy unlock_time po zablokowaniu konto będzie musiało być odblokowane przez administratora systemu ręcznie.

* lock_time=N - definiuje czas (w sekundach) na jaki dostęp dla konta zostanie zablokowany po nieudanej próbie autoryzacji

* unlock_time=N to czas określony w sekundach, na jaki konto zostanie zablokowane po blokadzie określonej przez deny nieudanych prób logowania.

* even_deny_root spowoduje, że konto roota również będzie blokowane, tak jak zwykłe konto (domyślnie nie jest). Parametr ten używany jest najczęściej z root_unlock_time=N, który definiuje czas po jakim dostęp zostanie odblokowany.

* silent zagwarantuje brak wyświetlania informacji o logowaniu userowi

* file=/sciezka/do/pliku pozwoli nam zdefiniować inny od standardowego var/log/tallylog plik przechowywania informacji o logowaniach.

Dla przykładu zdefiniujmy sobie taką regułę:

auth        required      pam_tally2.so deny=3 lock_time=10 unlock_time=60

Jaki będzie skutek? Moduł zablokuje dostęp do konta na 10 sekund po każdej nieudanej próbie logowania (podaniu błędnego hasła). Po trzech nieudanych próbach (w tym wypadku nieudane próby liczone są co 10 sekund) na 60 sekund zostanie zablokowana możliwość zalogowania się na konto.
System nie informuje użytkownika o powodzie nieudanego logowania i każda próba po blokadzie czasowej konta wygląda, jakby wprowadzane hasło było niepoprawne.

Statystyki nieudanych logowań

Moduł posiada niewielki interfejs pozwalający administratorowi na weryfikację ilości nieudanych logowań oraz czasu i adresu źródłowego wystąpienia ostatniego z nich.

[root@ipaclient1 pam.d]# pam_tally2
Login           Failures Latest failure     From
root                1    10/02/15 17:42:15  server.ipa.local
test                8    10/02/15 17:38:41  server.ipa.local

Jak widać system odnotował 8 nieudanych prób logowania na konto użytkownika test, z czego ostatnie o 17:38:41 z maszyny server.ipa.local, oraz jedną nieudaną próbę logowania na root-a... Wyświetlane wyniki możemy ograniczyć do jednego tylko usera poprzez parametr -u username.

Dzięki interfejsowi możemy dodatkowo zrealizować jeszcze jedno zadanie, mianowicie zresetować licznik nieudanych logowań dla użytkownika. Może to być przydatne w sytuacji, kiedy sami zapomnieliśmy hasła, a nie chcemy zaciemniać statystyk nieautoryzowanych prób logowania poprzez własne nieudane próby.

[root@ipaclient1 pam.d]# pam_tally2 -u test
Login           Failures Latest failure     From
test                8    10/02/15 17:38:41  server.ipa.local
[root@ipaclient1 pam.d]# pam_tally2 --reset=4 -u test
Login           Failures Latest failure     From
test                8    10/02/15 17:38:41  server.ipa.local
[root@ipaclient1 pam.d]# pam_tally2 -u test
Login           Failures Latest failure     From
test                4    10/02/15 17:38:41  server.ipa.local

Możemy również użyć krótkiej opcji -r, która wyzeruje licznik nieudanych logowań, a w przypadku kiedy nie określimy użytkownika, dla którego licznik ma być zresetowany, uwzględnione zostaną wszystkie konta.

[root@ipaclient1 pam.d]# pam_tally2 -r
Login           Failures Latest failure     From
root                1    10/02/15 17:53:17  server.ipa.local
test                1    10/02/15 17:53:40  server.ipa.local
[root@ipaclient1 pam.d]# pam_tally2

Jak widać podczas resetowania liczników pam_tally2 wyświetla ostatni status nieudanych logowań, a następnie je zeruje.

Centralna autentykacja - reguły sudo w IPA

Red Hat 6.x / CentOS 6.x

Centralna autentykacja pozwala nam z jednego miejsca zarządzać dostępami dla użytkowników. Oczywistym rozszerzeniem możliwości kontrolowania samych dostępów dla użytkowników jest zarządzanie ich rozszerzonymi uprawnieniami sudo.

Ipa oferuje możliwość definiowania reguł sudo dla użytkowników czy grup użytkowników i zaaplikowanie ich na konkretny host lub grupę hostów. Samo konfigurowanie reguł można przeprowadzić przez webowy panel administracyjny IPA (dla leniwych), lub poprzez shella (dla ambitnych). U mnie lenistwo przewyższa ambicję ;).

Aby rozwiązanie to mogło być wykorzystane konieczna będzie dodatkowa konfiguracja zarówno po stronie serwera IPA jak i hosta-klienta.

Konfiguracja serwerów do używania zdalnych plików sudoers

Pierwszym krokiem jaki musimy wykonać (jednorazowo dla każdej domeny ipa) jest zdefiniowanie hasła dla użytkownika sudo. Jako, że definicje użytkownika rezydują w ldap-ie, użyjemy komendy ldappasswd:

[root@server ipa]# ldappasswd -Y GSSAPI -S -h server.ipa.local uid=sudo,cn=sysaccounts,cn=etc,dc=ipa,dc=local
New password: {haslo_sudo}
Re-enter new password: {haslo_sudo}
SASL/GSSAPI authentication started
SASL username: admin@IPA.LOCAL
SASL SSF: 56
SASL data security layer installed.

Credentiali tych używać będziemy do konfiguracji autentykacji na wszystkich hostach klienckich. Przejdźmy zatem do ich konfiguracji (tą powtarzamy na wszystkich maszynach korzystających z logowania poprzez IPA).

W pierwszej kolejności musimy odblokować możliwość korzystania przez system ze zdalnego sudoers. Odbywa się to przez edycję pliku /etc/nsswitch.conf, a dokładniej dodanie ldap do definicji sudoers:

[root@ipaclient1 ipa]# vi /etc/nsswitch.conf
...
sudoers: files ldap sss
...

Kolejnym krokiem będzie konfiguracja samego ldap-a z którego sudo ma korzystać:

[root@ipaclient1 ipa]# vi /etc/sudo-ldap.conf
 
binddn uid=sudo,cn=sysaccounts,cn=etc,dc=ipa,dc=local
bindpw 1qazXSW@
ssl start_tls
tls_cacertfile /etc/ipa/ca.crt
tls_checkpeer yes
uri ldap://server.ipa.local
sudoers_base ou=SUDOers,dc=ipa,dc=local
bind_timelimit 30
timelimit 30

Powyższe linie należy odkomentować i zmodyfikować (elementy wymagające modyfikacji zaznaczyłem na żółto). bindpw to hasło, które ustawialiśmy wcześniej dla sudo. Pozostałe pozycje są raczej oczywiste.

Pozostaje nam jeszcze definicja domeny NIS - zalecana przez Red Hat, choć całość w podstawowej wersji działa również bez tego:

[root@ipaclient1 ipa]# vi /etc/rc.d/rc.local
...
nisdomainname ipa.local
...

Jako, że dane są w zasadzie stałe dla wszystkich maszyn-klientów, w prosty sposób możemy oskryptować te działania, ułatwiając sobie pracę.

Definiowanie reguł sudo poprzez panel www IPA

Całością konfiguracji sudo od strony panelu administracyjnego IPA zarządzamy w zasadzie poprzez trzy zakładki umieszczone w Policy > Sudo:

Definiowanie reguł sudo rozpoczynamy od określenia komendy jaka ma być przez taką regułę obsługiwana:

Definicja ta zawierać musi pełną komendę jaką użytkownik będzie mógł wykonać poprzez sudo, np /bin/cat /etc/shadow. Ważne jest, żeby poszczególne komendy (jak w tym wypadku cat) podawać z pełną ścieżką w systemie, gdyż inaczej sudo może nie zadziałać.

TIP: Jeśli nie wiesz w jakiej lokalizacji znajduje się dana binarka możesz użyć polecenia which komenda.

Kolejnym poziomem - opcjonalnym - mogą być grupy sudo. Możemy tu zebrać w jeden kontener kilka zdefiniowanych komend, aby posługiwać się nimi podczas tworzenia reguł. Podczas tworzenia grupy definiujemy jedynie jej nazwę, a po utworzeniu uzupełniamy o komendy, które chcemy w grupie umieścić.

Ostatnim poziomem jest utworzenie właściwej reguły sudo, która precyzuje komendy, użytkowników oraz hosty, na których ma działać.
Sudo rules > Dodaj wywoła proste okno, w którym zdefiniujemy nazwę reguły. Warto w nazwie zawierać możliwie dużo zwięzłych informacji, aby przy wielu regułach nie mieć problemów z ich identyfikacją, np:

Po zdefiniowaniu możemy przejść do ustawień reguły, poprzez kliknięcie na jej nazwę. Konfiguracja odbywa się na jednej stronie posegregowanej w kilka sekcji:

* General - opis reguły
* Options - opcje komendy sudo
* Who - definicje użytkowników uprawnionych do korzystania z reguły
* Access this host - definicje hostów na których reguła ma działać
* Run commands - komendy które mogą być uruchamiane w ramach reguły
* As whom - z uprawnieniami jakiego usera komenda ma być wykonana (domyśnie jest to root).

Wszystkie sekcje poza Options umożliwiają wybranie zdefiniowanych wcześniej pozycji, np. hostów, grup hostów, użytkowników, komend itd. Wszystkie z nich mają również checkbox "Any", umożliwiający wybranie wszystkich możliwości z danej sekcji (poniżej na żółto). Ja zgodnie z nazwą skonfigurowałem regułę, aby na wszystkich hostach pozwalała wykonać cat na /etc/shadow:

Jak widać uprawnienia do reguły posiada jedynie user test1.

Ważnym elementem definicji reguł są opcje sudo, które możemy uwzględniać w każdej z nich z osobna. Wszystkie opcje opisane są na stronie manuala sudo choć mało która jest używana często.

Do używanych najczęściej bez wątpienia należy odpowiednik "NOPASSWD" z tradycyjnego pliku /etc/sudoers, czyli !authenticate. Opcja pozwala wykonywać użytkownikowi sudo nie wymagając od niego żadnej dodatkowej autoryzacji:

Po tych definicjach możemy zweryfikować działanie naszej reguły logując się na dowolny host jako user test1 i porównując działania komendy z oraz bez sudo:

[root@ipaclient1 ipa]# su test1
sh-4.1$ cat /etc/shadow
cat: /etc/shadow: Permission denied
sh-4.1$ sudo cat /etc/shadow
root:$6$12o5DXryNHU2IFiH$NzNc/EU8SonPDxDNHFDjbdK6JCVMoaGd99BJ8L9xz6mRyiLkCkY4cPNpDWgvc91aXgcwHzDN4e9WKEIH3XCAs.:16671:0:99999:7:::
bin:*:15980:0:99999:7:::
daemon:*:15980:0:99999:7:::
adm:*:15980:0:99999:7:::
lp:*:15980:0:99999:7:::
sync:*:15980:0:99999:7:::
shutdown:*:15980:0:99999:7:::
halt:*:15980:0:99999:7:::
...

Użytkownik będąc zalogowanym na serwerze może zweryfikować swoje upranienia sudo w zwyczajny sposób, tj. poprzez sudo -l.

Jedną z koniecznych reguł będzie dla każdego administratora uzyskanie pełnego dostępu do własnych systemów. W IPA osobne omawianie tematu nie jest chyba konieczne. Po prostu zdefiniuj komendę jako Any Command, nie zapomnij o !authenticate i dobrej nazwie, np:

Resetowanie zapomnianego hasła administracyjnego IPA oraz Directory Managera LDAP

Red Hat 6.x / CentOS 6.x

Po skakaniach z tematu na temat i klikaniu różnych rzeczy na maszynach wirtualnych, pewnego dnia zaszła potrzeba, aby powrócić do IPA, żeby przetestować możliwość realizacji jednego z pomysłów. Oczywiście powrót nie okazał się zbyt prosy, ponieważ okazało się, że nie mam pojęcia jakie hasło ustawiłem dla użytkownika admin... Jak by tego było mało, jeśli dobrze pamiętam identyczne hasło ustawiłem dla usera administracyjnego LDAP-a, tak na wszelki wypadek, żeby łatwiej było zapamiętać....
Wyjścia były dwa - przeinstalować całość IPA (co nie byłoby takie złe, bo taka instalacja to dobre ćwiczenie na pamięć), lub bardziej ambitnie spróbować włamać się na te konta. Podszedłem do tematu ambitnie ciekaw rezultatu. Okazało się, że odzyskiwanie haseł dla obu użytkowników jest sprawą banalną.

P.S. Jeśli pamiętasz hasło do swojego ldapa pierwszy krok możesz pominąć.

Odzyskiwanie hasła Directory Managera (admina LDAP)

Odzyskanie hasła dla tego użytkownika sprowadza się do jego brutalnej zmiany na nowe. W tym celu, w pierwszej kolejności konieczne będzie zatrzymanie serwisu dirsrv:

[root@server ~]# service dirsrv stop
Shutting down dirsrv:
    IPA-LOCAL...                                           [  OK  ]
    PKI-IPA...                                             [  OK  ]

Do podmiany hasła będzie nam potrzebny hash nowego hasła. Uzyskamy go poprzez:

[root@server ~]# pwdhash nasze_haslo
{SSHA}jobpzl0uKb0iZ7cIu8/HKm/Er9lxJfp+jftzYQ==

Kolejnym krokiem będzie podmiana hasła. W tym celu musimy wyedytować jeden plik.
I tu uwaga. Lokalizacja pliku będzie nieco inna zależnie od instancji dla jakiej pracuje. Lokalizacja pliku wygląda następująco: /etc/dirsrv/sldap-instancja/
Mój ldap pracuje dla IPA w domenie ipa.local więc katalogiem będzie /etc/dirsrv/sldap-IPA-LOCAL/.
Plikiem, który należy wyedytować jest dse.ldif.

[root@server ~]# vi /etc/dirsrv/slapd-IPA-LOCAL/dse.ldif

W pliku tym musimy znaleźć linijkę zawierającą stare hasło:

nsslapd-rootpw: {SSHA}x03lZLMyOPaGH5VB8fcys1IV+TVNbBIOwZEYoQ==

i oczywiście podmienić hash hasła na ten uzyskany przy użyciu komendy pwdhash.

Pozostaje nam jeszcze wystartować usługę:

[root@server ~]# service dirsrv start
Starting dirsrv:
    IPA-LOCAL...                                           [  OK  ]
    PKI-IPA...                                             [  OK  ]

Reset hasła admina IPA

Odzyskiwanie hasłą usera admin w IPA jest "grzeczniejsze" i nie wymaga ingerencji w pliki. W pierwszej kolejności musimy wyeksportować do zmiennej systemowej lokalizację naszego certyfikatu IPA. Domyślnie będzie to:

[root@server ~]# export LDAPTLS_CACERT=/etc/ipa/ca.crt

Możemy teraz zmienić hasło admina

[root@server ~]# ldappasswd -ZZ -D 'cn=directory manager' -W -S uid=admin,cn=users,cn=accounts,dc=ipa,dc=local -H ldap://server.ipa.local
New password: {nowe_haslo_admina}
Re-enter new password: {nowe_haslo_admina}
Enter LDAP Password: {haslo_directory_managera}

 Zaznaczone wartości, tj. domenę oraz adres katalogu ldap należy oczywiście dostosować do własnego środowiska.

Zarządzanie listą kontroli dostępu - ACL

RedHat 6.x / CentOS 6.x

Poza standardowym systemem przyznawania dostępów do plików opartym o właściciela oraz grupę, w systemach rodziny RedHat zaimplementowana jest również inna metoda.
Access Control List (ACL) umożliwia nam gradację dostępów do zasobów dla poszczególnych użytkowników czy kilku grup, na różnych poziomach uprzywilejowania.

Weryfikacja ACL

Do weryfikacji przydzielonych już uprawnień posłuży nam komenda:

[root@centos67 mnt]# getfacl test_acl.txt
# file: test_acl.txt
# owner: root
# group: root
user::rw-
group::r--
other::r--

Zwrócone informace mówią nam, że właścicielem pliku jest root, grupą również root, oraz, że właściciel posiada uprawnienia "rw" do tego pliku, a grupa i pozostali jedynie "r". Nie widzimy tu informacji o żadnych dodatkowych uprawnieniach, które mogły by być nadane dla pliku.
Widok ten jednak zmienia się po dodaniu uprawnień:

[root@centos67 mnt]# getfacl test_acl.txt
# file: test_acl.txt
# owner: root
# group: root
user::rw-
user:test:rw-
group::r--
group:test2:r-x
mask::rwx
other::r--

Jak łatwo zauważyć, teraz, poza domyślnymi uprawnieniami, przybyły nam dodatkowe pozycje. Widzimy, że teraz, poza użytkownikiem root, dostęp w trybie "rw" ma również użytkownik test, a także, że grupa test2 posiada uprawnienia typu "rx".Co prawda wartości uprawnień możemy zweryfikować jedynie podglądając je poprzez getfacl, ale przydzielenie uprawnień objawi się nam w systemie w jeszcze jeden, charakterystyczny, i widoczny na pierwszy rzut oka sposób:

[root@centos67 mnt]# ll
-rw-rwxr--+ 1 root root     0 Sep  9 17:28 test_acl.txt

W ostatnim polu określającym uprawnienia dla pliku pojawił się nam "+". Jest to znak, którego szukamy.

Operowanie na uprawnieniach ACL

Nadawanie uprawnień dla użytkowników i grup stanowi efektywny sposób kontroli dostępu do plików w naszym systemie. Samo dodanie będziemy realizowali poprzez polecenie, o następującej składni:

[root@centos67 mnt]# setfacl -m u:test:rw test_acl.txt

Polecenie jest skonstruowane wg zasady:
* -m - modyfikacja wpisu (dodanie lub zmiana parametrów dostępu)
* rodzaj:nazwa:uprawnienia - rodzajem może być u (user), g (group), o (other) lub m (mask). W przypadku opcji u i g w sekcji "nazwa" możemy podać nazwę konkretnego użytkownika lub grupy, a uprawnienia to zwyczajne uprawnienia "rwx".

Zgodnie z tą zasadą powyższa komenda spowoduje modyfikację (-m) wpisu dla użytkownika (u) o nazwie test, przydzielając mu uprawnienia "rw" do pliku test_acl.txt.

Usuwanie uprawnień specjalnych możemy zrealizować na dwa sposoby. Jeśli chcemy usunąć uprawnienia przyznane konkretnemu userowi lub grupie, skorzystamy z opcji:

[root@centos67 mnt]# setfacl -x u:test test_acl.txt

Oczywiście sekcja u:test będzie wyznacznikiem tego, co zostanie usunięte.
Możemy również wyczyścić całą tablicę ACL, usuwając wszystkie przyznane uprawnienia:

[root@centos67 mnt]# setfacl -b test_acl.txt

Maska i uprawnienia default

Poza przydzielaniem konkretnych uprawnień konkretnym userom czy grupom, mamy również możliwość określenia maski dostępu do pliku. Maska taka ma na celu określenie maksymalnych uprawnień, jake ktokolwiek zdefiniowany poprzez ACL może uzyskać.
Należy pamiętać, że maska nadpisuje uprawnienia przyznane indywidulanie.
Np. jeśli dla użytkownika określono poprzez ACL dostęp typu "rx", ale maska zawiera jedynie flagi "rw", oznaczać to będzie, że ten użytkownik będzie miał przyznany jedynie dostęp "r", ponieważ maskowanie nie dopuszcza wykonywania pliku. Jednym zdaniem, użytkownik ma takie uprawnienia acl, które zawarte są w masce pliku.
Maskę zdefiniujemy w następujący spsób:

[root@centos67 mnt]# setfacl -m m:r test_acl.txt

Spostrzegawczy zauważą, że po dodaniu uprawnień dla użytkownika, w getfacl dla naszego pliku pozycja mask: pojawia się automatycznie. Jeśli nie zmienimy jej ręcznie, będzie ona zawierać wszystkie uprawnienia, jakie przydzieliliśmy przez ACL-e.

Drugą właściwością jaką możemy określić, jest wartość default. Wartość ta, ustawiona dla katalogu spowoduje, iż wszystkie pliki tworzone w takim katalogu będą posiadać uprawnienia określone jako default.
Istotną rzeczą jest fakt, iż nadanie tych uprawnień nie będzie miało wpływu na uprawnienia istniejących już w katalogu plików, a jedynie na nowo utworzone.

Deklarowanie wartości, jako domyślnej odbywa się poprzez dodanie parametru d: na początku opcji acl, czyli przykładowo:

[root@centos67 mnt]# setfacl -m d:g:test2:rw /mnt/

Od tej pory, wszystkie pliki tworzone w katalogu /mnt będą posiadały acl group:test2:rw.

Troubbleshooting

Próba dodania nowych ACL-i kończy się informacją:

[root@centos67 mnt]# setfacl -m u:test2:rwx dd.sh
setfacl: dd.sh: Operation not supported

Należy zweryfikować, czy filesystem na którym próbujemy dodać acl-e posiada dodaną w opcjach mountowania obsługę tej funkcji:

[root@centos67 mnt]# mount
...
/dev/mapper/vg_luks-test on /mnt type ext2 (rw)
...

Widać powyżej, że filesystem jest zamountowany jedynie z opcją rw.
Aby umożliwić nadanie uprawnień przez acl-e musimy przemountować go z odpowiednią opcją:

[root@centos67 mnt]# mount -o remount,acl /mnt/
[root@centos67 mnt]# mount
/dev/mapper/vg_luks-test on /mnt type ext2 (rw,acl)

Działanie to nie jest permanentne i po restarcie systemu alc-e znów nie będą działać. Aby to zmienić należy dodać odpowiedni wpis przy naszym punkcie mountowania w /etc/fstab

[root@centos67 mnt]# vi /etc/fstab
/dev/mapper/vg_luks-test /mnt ext2 rw,acl 0 0

TIP: Zmiana domyślnych uprawnień plików tworzonych przez userów - umask

RedHat 6.x / CentOS 6.x

To, z jakimi uprawnieniami poszczególni użytkownicy tworzą pliki, nie jest ściśle narzucone przez system. Wartość jest zdefiniowana, i możliwa jest jej zmiana.

Domyślnie użytkownicy z UID większym niż 199 tworzą w systemie pliki z uprawnieniami na poziomie 664, czyli rw-rw-r--.
Zmiana tej reguły sprowadza się do edycji 2 plików: /etc/bashrc oraz /etc/profile.
Za nadane uprawnienia odpowiada w tych plikach polecenie umask. Wartość podanych przy nim uprawnień będzie odjęta od domyślnie pełnych 666, tak więc domyślna wartość 002 po odjęciu od 666 da nam 664.

Zdefiniowana w plikach wartość jest nadpisywana przez wartość zdefiniowaną przez użytkownika w pliku ~/.bashrc, a na potrzeby jednej sesji może być zmieniona przez polecenie:

[test@centos67 ~]$ umask 0004

Obecny poziom możemy sprawdzić wydająć polecenie:

[test@centos67 ~]$ umask
0004

Centralna autentykacja przy użyciu Identity Management (IdM) - klaster HA - tworzenie repliki serwera IPA

RedHat 6.x / CentOS 6.x

Dla zapewnienia wysokiej dostępności usługi autentykacyjnej, IPA oferuje mechanizm replikacji serwera centralnego. Operacja polega na utworzeniu repliki pierwszego serwera, i utworzenia na jego podstawie kopii, która będzie pracowała z nim w klastrze.

Operację rozpoczynamy od przygotowania zrzutu konfiguracji głównego serwera, czyli wspomnianej wcześniej repliki:

[root@server ~]# ipa-replica-prepare server2.ipa.local
Directory Manager (existing master) password:[haslo]

Preparing replica for server2.ipa.local from server.ipa.local
Creating SSL certificate for the Directory Server
Creating SSL certificate for the dogtag Directory Server
Creating SSL certificate for the Web Server
Exporting RA certificate
Copying additional files
Finalizing configuration
Packaging replica information into /var/lib/ipa/replica-info-server2.ipa.local.gpg

Po utworzeniu repliki jesteśmy informowani, że konfiguracja została zapisana w pliku /var/lib/ipa/replica-info-server2.ipa.local.gpg. Plik ten kopiujemy na serwer, na którym mamy uruchomić drugą instancję, w naszym wypadku na server2.ipa.local.

[root@server ~]# scp /var/lib/ipa/replica-info-server2.ipa.local.gpg root@server2.ipa.local:/tmp/
root@server2.ipa.local's password:
replica-info-server2.ipa.local.gpg                                             100%   35KB  35.1KB/s   00:00

Po zalogowaniu się na serwer server2.ipa.local należy dokonać instalacji serwera IPA z wykorzystaniem przygotowanego wcześniej pliku konfiguracji. W pierwszej kolejności należy doinstalować niezbędne pakiety ipa-server:

[root@server2 ~]# yum -y install ipa-server

Konieczne rónież będzie otwarcie portów na lokalnym FW, tak jak w przypadku instalacji pierwszego serwera.

[root@server2 ~]# iptables -I INPUT 5 -p tcp -m multiport --dports=80,443,389,636,88,464 -j ACCEPT
[root@server2 ~]# iptables -I INPUT 5 -p udp -m multiport --dports=88,464,123 -j ACCEPT
[root@server2 ~]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]

Teraz możemy przejść do właściwej instalacji repliki:

[root@server2 ~]# cd /tmp/
[root@server2 tmp]# ipa-replica-install replica-info-server2.ipa.local.gpg
Directory Manager (existing master) password: [haslo]

Run connection check to master
Check connection from replica to remote master 'server.ipa.local':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
admin@IPA.LOCAL password: [haslo]

Execute check on remote master
Check connection from master to remote replica 'server2.ipa.local':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

Connection from master to replica is OK.

Connection check OK
...
[Truncated output]
...

Po instalacji możemy w prosty sposób zweryfikować, czy nasza replika podłączyła się z serwerem centralnym, pobierając ticket kerberosa dla usera admin

[root@server2 tmp]# kinit admin
Password for admin@IPA.LOCAL:[haslo]
[root@server2 tmp]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@IPA.LOCAL

Valid starting     Expires            Service principal
08/30/15 17:51:10  08/31/15 17:51:07  krbtgt/IPA.LOCAL@IPA.LOCAL

Od tej chwili mamy również dostępną drugą konsolę webową Identity Management, pod adresem naszej repliki. Możemy z niej zweryfikować poprawność połączniea klastra, poprzez np. dodanie nowego użytkownika. Dodanie w jednej konsoli spowoduje propagację wartości na drugi serwer (i oczywiście pozostałe, jeśli replik jest więcej)

Centralna autentykacja przy użyciu Identity Management (IdM) - Instalacja IPA client - podłączanie do serwera centralnego

RHEL 6.x / CentOS 6.x

Aby aktywnie wykorzystywać możliwości centralnej autentykacji na naszych serwerach konieczne będzie zainstalowanie klienta IPA, oraz podłączenie go do domeny, którą stworzyliśmy przy okazji instalacji serwera IdM-owego.

Podłączanie rozpoczniemy od instalacji pakietów klienta:

[root@ipaclient1 ~]# yum install ipa-client

Tak, jak w przypadku instalacji ipa-server mamy możliwość instalacji klienta  poprzez parametyzację lub interaktywnie odpowiadając na pytania instalatora.
Niestety instalator nie zadaje nam jednego istotnego pytania, dotyczącego tworzenia katalogów domowych dla użytkowników logujących się przy użyciu kont IPA, dlatego ten element trzeba podać podczas instalacji jako parametr.

Instalator podłącza się do serwera centralnego, aby uzyskać autoryzację, dlatego przed uruchomieniem procesu warto wybić w naszym firewallu dziurki komunikacyjne:

[root@ipaclient1 ~]# iptables -I INPUT 5 -p tcp -m tcp --dport=80 -j ACCEPT
[root@ipaclient1 ~]# iptables -I INPUT 5 -p tcp -m tcp --dport=88 -j ACCEPT
[root@ipaclient1 ~]# iptables -I INPUT 5 -p tcp -m tcp --dport=389 -j ACCEPT
[root@ipaclient1 ~]# iptables -I INPUT 5 -p udp -m udp --dport=88 -j ACCEPT
[root@ipaclient1 ~]# iptables -I INPUT 5 -p tcp -m tcp --dport=464 -j ACCEPT
[root@ipaclient1 ~]# iptables -I INPUT 5 -p udp -m udp --dport=464 -j ACCEPT
[root@ipaclient1 ~]# iptables -I INPUT 5 -p udp -m udp --dport=123 -j ACCEPT
[root@ipaclient1 ~]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]

Warto również, jeśli nie korzystamy z serwera DNS dodać lokalnie w /etc/hosts dodać wpis serwera IPA

[root@ipaclient1 ~]# echo "192.168.1.110   server.ipa.local" >> /etc/hosts

Sama instalacja przebiega następująco:

[root@ipaclient1 ~]# ipa-client-install --mkhomedir
DNS discovery failed to determine your DNS domain
Provide the domain name of your IPA server (ex: example.com): ipa.local
Provide your IPA server name (ex: ipa.example.com): server.ipa.local
The failure to use DNS to find your IPA server indicates that your resolv.conf file is not properly configured.
Autodiscovery of servers for failover cannot work with this configuration.
If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure.
Proceed with fixed values and no DNS discovery? [no]: yes
Hostname: ipaclient1.example.com
Realm: IPA.LOCAL
DNS Domain: ipa.local
IPA Server: server.ipa.local
BaseDN: dc=ipa,dc=local

Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened.
Password for admin@IPA.LOCAL:[haslo]
Successfully retrieved CA cert
    Subject:     CN=Certificate Authority,O=IPA.LOCAL
    Issuer:      CN=Certificate Authority,O=IPA.LOCAL
    Valid From:  Thu Aug 27 17:26:30 2015 UTC
    Valid Until: Mon Aug 27 17:26:30 2035 UTC

Enrolled in IPA realm IPA.LOCAL
Attempting to get host TGT...
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm IPA.LOCAL
trying https://server.ipa.local/ipa/xml
Forwarding 'env' to server u'https://server.ipa.local/ipa/xml'
Hostname (ipaclient1.example.com) not found in DNS
Failed to update DNS records.
Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Forwarding 'host_mod' to server u'https://server.ipa.local/ipa/xml'
Could not update DNS SSHFP records.
SSSD enabled
Configuring ipa.local as NIS domain
Configured /etc/openldap/ldap.conf
NTP enabled
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Client configuration complete.

Instalator nie zwrócił błędu, więc przetestujmy, czy podłączenie przebiegło pomyślnie:

[root@ipaclient1 ~]# id
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[root@ipaclient1 ~]# getent passwd admin
admin:*:418600000:418600000:Administrator:/home/admin:/bin/bash
[root@ipaclient1 ~]# id admin
uid=418600000(admin) gid=418600000(admins) groups=418600000(admins)

Jak widać, lokalnie jesteśmy zalogowani na root-a, ale możemy pobrać dane identyfikacyjne usera admin, który jest userem rejestrowanym jedynie w IPA.
Od tego momentu możemy również logować się użytkownikami IdM, np. na wywołanego wcześniej admina:

login as: admin
admin@192.168.1.111's password:[haslo]
Creating home directory for admin.
[admin@ipaclient1 ~]$ id
uid=418600000(admin) gid=418600000(admins) groups=418600000(admins) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Nasz host jest już również widoczny w panelu administracyjnym IPA:

Centralna autentykacja przy użyciu Identity Management (IdM) - Instalacja IPA server

OS: RHEL 6.x / CentOS 6.x

Systemy rodziny RedHat oferują możliwość realizacji centralnej autentykacji użytkowników poprzez wykorzystanie oprogramowania typu IdM wprost z repozytorium systemowego.
Oprogramowanie udostęnia nam prosty, przejrzysty interfejs www do centralnego zarządzania użytkownikami, grupami oraz uprawnieniami na poszczególnych maszynach. Zalety takiego sposobu zarządzania dostępami przy większej ilości serwerów są oczywiste.

Instalacja IPA Server

Instalacja i działanie serwera IPA wymaga skonfigurowania hostname'a maszyny jako  ( WAŻNE! ) pełnej nazwy domenowej (FQN), i dodania go do pliku /etc/hosts. Moja konfiguracja wygląda następująco:

[root@server ~]# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=server.ipa.local
GATEWAY=192.168.1.1

[root@server ~]# cat /etc/hosts
127.0.0.1               localhost.localdomain localhost
::1             localhost6.localdomain6 localhost6
192.168.1.110   server.ipa.local server

Czyli serwer nazywać się będzie server, znajdować się będzie w domenie ipa.local i mieć będzie adres 192.168.1.110.
Po skonfigurowaniu pliku hosts możemy przystąpić do właściwej instalacji:

[root@ipa-server ~]# yum -y install ipa-server

Po instalacji paczki wraz z ponad 80 zależnościami, możemy przystąpić do tworzenia instancji serwera IPA na naszej maszynie. Instalacja może odbywać się interaktywnie, jak i przez deklarację odpowiednich opcji, których przegląd dostępny jest w helpie dla samego instalatora (ipa-server-install --help). W podstawowej wersji zupełnie wystarczająca jest instalacja interaktywna, i taką przeprowadzimy:

[root@server ~]# ipa-server-install

The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
This program will set up the IPA Server.

This includes:
  * Configure a stand-alone CA (dogtag) for certificate management
  * Configure the Network Time Daemon (ntpd)
  * Create and configure an instance of Directory Server
  * Create and configure a Kerberos Key Distribution Center (KDC)
  * Configure Apache (httpd)

To accept the default shown in brackets, press the Enter key.

Enter the fully qualified domain name of the computer
on which you're setting up server software. Using the form
.
Example: master.example.com.


Server host name [server.ipa.local]: [enter]

The domain name has been determined based on the host name.

Please confirm the domain name [ipa.local]: [enter]

The kerberos protocol requires a Realm name to be defined.
This is typically the domain name converted to uppercase.

Please provide a realm name [IPA.LOCAL]: [enter]
Certain directory server operations require an administrative user.
This user is referred to as the Directory Manager and has full access
to the Directory for system management tasks and will be added to the
instance of directory server created for IPA.
The password must be at least 8 characters long.

Directory Manager password: [haslo]
Password (confirm): [haslo]

The IPA server requires an administrative user, named 'admin'.
This user is a regular system account used for IPA server administration.

IPA admin password: [haslo]
Password (confirm): [haslo]


The IPA Master Server will be configured with:
Hostname:      server.ipa.local
IP address:    192.168.1.110
Domain name:   ipa.local
Realm name:    IPA.LOCAL

Continue to configure the system with these values? [no]: yes

The following operations may take some minutes to complete.
Please wait until the prompt is returned.

Po krótkiej ankiecie nastąpi konfiguracja niezbędnych usług jak np. ntp, serwera certyfikatów, kerberosa czy httpd do interfejsu www samego IdM-a. Jak widać powyżej, nasz serwer będzie działał w domenie ipa.local, a jego królestwem kerberosowym będzie IPA.LOCAL. (Kerberos to temat na inny tekst - przy IPA nie jest konieczna jego znajomość)

Po instalacji zostaniemy poinformowani o konieczności otwarcia portów, możliwości uzyskania ticketu kerberosowego czy zaleceniu backupu pliku klucza:

Setup complete

Next steps:
        1. You must make sure these network ports are open:
                TCP Ports:
                  * 80, 443: HTTP/HTTPS
                  * 389, 636: LDAP/LDAPS
                  * 88, 464: kerberos
                UDP Ports:
                  * 88, 464: kerberos
                  * 123: ntp

        2. You can now obtain a kerberos ticket using the command: 'kinit admin'
           This ticket will allow you to use the IPA tools (e.g., ipa user-add)
           and the web user interface.

Be sure to back up the CA certificate stored in /root/cacert.p12
This file is required to create replicas. The password for this
file is the Directory Manager password

Jeśli instalacja przebiegła poprawnie, powinniśmy być w stanie uzyskać ticket kerberosa zgodnie z poprzednią informacją:

[root@server ~]# kinit admin
Password for admin@IPA.LOCAL:[haslo]
[root@server ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@IPA.LOCAL

Valid starting     Expires            Service principal
08/27/15 19:35:15  08/28/15 19:35:11  krbtgt/IPA.LOCAL@IPA.LOCAL

Mamy ticket, więc nasza instalacja przebiegła poprawnie. Powinniśmy móc zalogować się również poprzez interfejs www, odwiedzając poprzez przeglądarkę adres IP naszego serwera IPA:

Korzystając z credentiali, jakie podaliśmy podczas instalacji IPA, logujemy się do panelu administracyjnego (user: admin):

Voila! Mamy działający serwer centralnej autoryzacji.

Troubbleshooting

Manager IPA nie otwiera się w przeglądarce po instalacji:
najczęściej winy jest:

* brak otwarcia FW dla portów IPA

[root@server ~]# iptables -I INPUT 5 -p tcp -m tcp --dport 80 -j ACCEPT
[root@server ~]# iptables -I INPUT 5 -p tcp -m tcp --dport 443 -j ACCEPT
[root@server ~]# iptables -I INPUT 5 -p tcp -m tcp --dport 389 -j ACCEPT
[root@server ~]# iptables -I INPUT 5 -p tcp -m tcp --dport 636 -j ACCEPT
[root@server ~]# iptables -I INPUT 5 -p tcp -m tcp --dport 88 -j ACCEPT
[root@server ~]# iptables -I INPUT 5 -p tcp -m tcp --dport 464 -j ACCEPT
[root@server ~]# iptables -I INPUT 5 -p udp -m udp --dport 88 -j ACCEPT
[root@server ~]# iptables -I INPUT 5 -p udp -m udp --dport 464 -j ACCEPT
[root@server ~]# iptables -I INPUT 5 -p udp -m udp --dport 123 -j ACCEPT
[root@server ~]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK   ]

* niemożność rozwiązania DNS nazwy serwera IPA

W przypadku środowisk serwerowych należy dodać odpowiednie wpisy w DNS-ach.
Dla lokalnego środowiska wirtualnego, w którym nie ma możliwości ingerencji we wpisy serwerów DNS, rozwiązaniem problemu będzie dodanie na maszynie, z której próbujemy otworzyć stronę IPA wpisu:

192.168.1.110     server.ipa.local

do pliku hosts:
* dla OS Linux w /etc/hosts
* dla OS Windows w C:\Windows\System32\drivers\etc\hosts

TIP: Szybkie blokowanie możliwości logowania po ssh

OS: Linux

Jeśli potrzebujemy "na szybko" zablokować możliwość logowania się użytkowników (poza rootem) możemy wykorzystać prosty trick:

[root@server ~]# touch /etc/nologin

Dopóki plik istnieje na serwerze logować może się tylko root.

TIP: Wykrywanie zduplikowanych id użytkowników

OS: Linux

Zdarza się, że użyszkodnicy podmieniają UID konta, ustawiając je na takie samo, jak inne konto - np na UID 0 czyli root.

Zdarzenie takie wyłapiemy prostym zapytaniem:

[root@server ~]# cat /etc/passwd | cut -d: -f3 | sort -n | uniq -d

dla jasności:
cut -d: -f3       tnie linijkę, jako separator pola używająć :, i zwraca trzecie pole (w tym wypadku UID usera)
sort -n       sortuje UID-y traktując je jako znaki numeryczne
uniq -d      wyświetla tylko zduplikowane wartości