[OpenBSD]

[Wstecz: Problemy z FTP] [Spis treści] [Dalej: Redundantny firewall z CARP i pfsync]

PF: Authpf: powłoka dla bramek uwierzytelniających


Spis treści


Wstęp

Authpf(8) jest powłoką użytkownika służącą do uwierzytelniania w bramkach sieciowych. Bramka uwierzytelniająca nie różni się od zwykłej bramki sieciowej (aka router) z tym wyjątkiem, że użytkownicy muszą potwierdzić swoją tożsamość na bramce, zanim ich ruch będzie mógł zostać przepuszczony przez nią. Gdy domyślną powłoką użytkownika jest /usr/sbin/authpf (np zamiast normalnie stosowanych powłok: ksh(1), csh(1), itp), a użytkownik zaloguje się przez SSH, authpf zajmie się wykonaniem odpowiednich operacji, aby aktywować zestaw reguł pf(4) i spowodować, że działa obsługa ruchu związanego z danym użytkownikiem jak np reguły filtrujące i/lub translacje NAT czy przekierowania. Gdy użytkownik wyloguje się lub następuje zamknięcie jego sesji, authpf usuwa wszystkie reguły załadowane dla tego użytkownika i zamyka wszystkie otwarte przez niego połączenia stanowe. Dzięki temu, użytkownik może przesyłać pakiety przez bramkę jedynie w czasie, gdy utrzymuje otwartą sesję SSH.

Authpf ładuje reguły filtra/NAT w unikany punkt zakotwiczenia (anchor). Nazwa tego zakotwiczenia jest kombinacją uniksowej nazwy użytkownika oraz numeru procesu authpf w formacie "username(PID)". Każde zakotwiczenie dla użytkownika przechowywane jest wewnątrz zakotwiczenia authpf które jest zakotwiczone w jednym kroku w głównym zestawie reguł. Zatem "fully qualified anchor path" staje się:

main_ruleset/authpf/username(PID)

Reguły które ładuje authpf mogą być konfigurowane per użytkownik lub globalnie.

Przykładowe zastosowania authpf to:

Authpf zapewnia logi z nazwami użytkowników i ich adresami IP dla każdego użytkownika, który pomyślnie przechodzi uwierzytelnianie, podobnie dzieje się z dokładnym czasem rozpoczęcia i zakończenia sesji odnotowywanymi przez syslogd(8). Wykorzystując te informacje, administrator może określić kto i kiedy był zalogowany oraz czyni użytkowników odpowiedzialnymi za swój ruch sieciowy.

Konfiguracja

Podstawowe kroki, niezbędne do konfiguracji authpf są wymienione poniżej. Bardziej szczegółowe informacje o konfiguracji można znaleźć na stronie podręcznika man authpf.

Włączanie Authpf

Authpf nie uruchomi się jeżeli plik konfiguracyjny /etc/authpf/authpf.conf nie istnieje. Nawet jeżeli ten plik jest pusty (o zerowym rozmiarze), musi wciąż być dostępny w przeciwnym wypadku authpf wyłączy się natychmiast po pomyślnym zalogowaniu użytkownika.

Poniższe parametry konfiguracyjne mogą zostać umieszczone w pliku authpf.conf:

Włączanie authpf do głównego zestawu reguł

Authpf jest włączane do (ang. linked into) głównego zestawu reguł przy pomocy reguł anchor:
nat-anchor "authpf/*"
rdr-anchor "authpf/*"
binat-anchor "authpf/*"
anchor "authpf/*"

Niezależnie od tego, gdzie w głównym zestawie reguł znajdzie się reguła anchor, PF rozgałęzi się, aby przetworzyć reguły authpf. Nie jest wymagana obecność wszystkich czterech reguł anchor, na przykład jeśli authpf nie jest skonfigurowane do ładowania reguł nat, reguła nat-anchor może zostać pominięta.

Konfigurowanie ładowanych reguł

Authpf ładuje swoje reguły z jednego z dwóch plików:

Pierwszy plik zawiera reguły, które są ładowane jedynie gdy $USER (które jest zastępowane przez nazwę użytkownika) zaloguje się. Konfiguracja reguł według użytkowników ma miejsce, gdy konkretny użytkownik -- jak np administrator -- wymaga zestawu reguł innego, niż domyślnie ustawiony. Drugi plik zawiera domyślne reguły, które są ładowane, gdy dowolny użytkownik nie posiada swojego własnego pliku authpf.rules. Jeśli plik ten dla konkretnego użytkownika istnieje, zastępuje domyślny plik. Przynajmniej jeden z plików musi istnieć, w przeciwnym razie authpf nie będzie działać.

Reguły filtrujące i translacyjne mają taką samą składnię, jak dowolny inny zestaw reguł PF, z jednym wyjątkiem: authpf daje możliwość korzystania z predefiniowanych makr:

Jest zalecaną praktyką, aby wykorzystywać makro $user_ip jedynie do zezwalania na ruch pakietów z komputera użytkownika, który potwierdził swoją tożsamość.

Dodatkowo do makra $user_ip, authpf authpf skorzysta z tabeli authpf_users (jeżeli istnieje) by przechowywać adresy IP dla każdego z uwierzytelnionych użytkowników. Upewnij się że ją zdefiniowałeś zanim jej użyjesz:

table <authpf_users> persist
pass in on $ext_if proto tcp from <authpf_users> \
    to port smtp flags S/SA keep state

Tabela ta powinna być używana tylko w regułach przeznaczonych zastosowania dla wszystkich uwierzytelnionych użytkowników.

Listy kontroli dostępu

Można uniemożliwić dostęp użytkownika przez authpf poprzez utworzenie pliku o nazwie użytkownika, który ma być zablokowany, w katalogu /etc/authpf/banned/. Zawartość pliku będzie wyświetlona użytkownikowi zanim authpf zerwie z nim połączenie. Dzięki temu, można w poręczny sposób powiadomić użytkownika dlaczego nie ma on prawa do połączenia się i z kim należy się skontaktować, aby odzyskać dostęp.

Można także umożliwiać dostęp odwrotnie, czyli jedynie poszczególnym użytkownikom poprzez umieszczanie nazw użytkowników w pliku /etc/authpf/authpf.allow. Jeśli plik /etc/authpf/authpf.allow nie istnieje, lub zawiera tylko "*", wówczas authpf zezwoli na dostęp wszystkim, których logowanie przez SSH zakończyło się sukcesem, pod warunkiem, że nie są zbanowani.

Jeśli authpf nie jest w stanie określić, czy użytkownik ma prawo dostępu, czy nie, wówczas wyświetla krótką wiadomość i rozłącza użytkownika. Wpis w /etc/authpf/banned/ zawsze nadpisuje wpis w /etc/authpf/authpf.allow.

Wyświetlanie wiadomości przy logowaniu

Za każdym razem gdy użytkownik pomyślnie się zautoryzuje do authpf, zostanie otrzyma powitanie informujące że został zautoryzowany.

Hello charlie. You are authenticated from host "64.59.56.140"

Wiadomość tą można uzupełnić poprzez umieszczenie zwyczajowej informacji w /etc/authpf/authpf.message. Zawartość tego pliku zostanie wyświetlona po domyślnym powitaniu.

Ustawianie authpf jako powłokę użytkownika

Aby authpf działało, musi być ustawione jako powłoka domyślna użytkownika. Gdy użytkownik pomyślnie potwierdza swoją tożsamość wobec sshd(8), authpf będzie uruchomione, jako powłoka użytkownika. Nastąpi wówczas sprawdzenie, czy użytkownik ma prawo dostępu do authpf, załadowanie reguł z odpowiedniego pliku itd.

Jest kilka sposobów na ustawienie authpf jako powłokę użytkownika:

  1. Ręcznie dla każdego użytkownika, przy pomocy chsh(1), vipw(8), useradd(8), usermod(8), itd.
  2. Poprzez ustawienie opcji shell w klasie zdefiniowanej w pliku /etc/login.conf, do której należy użytkownik lub też do której go przydzielimy.

Tworzenie klas logowania w authpf.

W przypadku gdy wykorzystujemy authpf w systemie który posiada normalne konta użytkowników oraz konta dla użytkowników authpf może być korzystne używanie oddzielnych klas logowania dla użytkowników authpf. Pozwala to na dokonywanie pewnych zmian dla tych kont w globalnej podstawie oraz na różne reguły dotyczące normalnych kont i kont z authpf. Przykłady reguł jakie można ustawić:

Klasy logowania tworzone są w pliku login.conf(5) OpenBSD dostarczany jest z klasą logowania authpf zdefiniowaną jako:

authpf:\
    :welcome=/etc/motd.authpf:\
    :shell=/usr/sbin/authpf:\
    :tc=default:

Użytkownicy są przypisywani do klas logowania poprzez edycję pola class w pliku passwd(5) dla danego użytkownika. Jedną z możliwości zrobienia tego jest użycie polecenia chsh(1).

Przeglądanie, kto jest zalogowany

Kiedy już użytkownik pomyślnie zaloguje się, a PF dostroi reguły PF, authpf zmienia znacznik procesu (ang. process title), aby wskazywać na nazwę zalogowanego użytkownika i jego adres IP:
    # ps -ax | grep authpf
    23664 p0  Is+     0:00.11 -authpf: charlie@192.168.1.3 (authpf)

Tutaj użytkownik charlie jest zalogowany z maszyny 192.168.1.3. Poprzez wysłanie sygnału SIGTERM do procesu authpf, użytkownik może zostać rozłączony siłą. Authpf usunie także wszystkie załadowane reguły i połączenia stanowe utworzone przez użytkownika.

    # kill -TERM 23664

Przykład

Authpf jest wykorzystywane w bramce sieciowej OpenBSD do uwierzytelniania użytkowników sieci bezprzewodowej, która jest częścią większej struktury sieciowej. Gdy użytkownik potwierdzi swoją tożsamość, zakładając, że nie jest na liście banów, będzie mógł łączyć się ze światem zewnętrznym przez SSH, przeglądać strony www (także bezpieczne połączenia www), a dodatkowo będzie miał prawo korzystać z dowolnego serwera DNS sieci w której się znajduje.

Plik /etc/authpf/authpf.rules zawiera następujące reguły:

wifi_if = "wi0"
pass in quick on $wifi_if proto tcp from $user_ip to port { ssh, http, \
   https } flags S/SA keep state

Użytkownik administrujący charlie musi mieć dostęp do serwerów SMTP i POP3 kampusu, a dodatkowo do surfowania po sieci i korzystania z SSH. Następujące reguły są ustawione w /etc/authpf/users/charlie/authpf.rules:

wifi_if = "wi0"
smtp_server = "10.0.1.50"
pop3_server = "10.0.1.51"
pass in quick on $wifi_if proto tcp from $user_ip to $smtp_server \
   port smtp flags S/SA keep state
pass in quick on $wifi_if proto tcp from $user_ip to $pop3_server \
   port pop3 flags S/SA keep state
pass in quick on $wifi_if proto tcp from $user_ip to port { ssh, http, \
   https } flags S/SA keep state

Główny zestaw reguł -- umieszczony w /etc/pf.conf -- jest skonfigurowany w następujący sposób:

# makra
wifi_if = "wi0"
ext_if  = "fxp0"

dns_servers = "{ 10.0.1.56, 10.0.2.56 }"
     
table <authpf_users> persist

scrub in all

# reguły filtrujące
block drop all


pass out quick on $ext_if inet proto tcp from \
  { $wifi_if:network, $ext_if } flags S/SA modulate state
pass out quick on $ext_if inet proto { udp, icmp } from \
   { $wifi_if:network, $ext_if } keep state
pass in quick on $wifi_if inet proto tcp from $wifi_if:network to $wifi_if \
   port ssh flags S/SA keep state
   
pass in quick on $wifi_if inet proto { tcp, udp } from <authpf_users> \
   to $dns_servers port domain keep state

anchor "authpf/*" in on $wifi_if

Zestaw reguł jest bardzo prosty, oto jak działa:

Myślą przewodnią głównego zestawu reguł jest: blokowanie wszystkiego i przepuszczanie minimalnej ilości jasno sprecyzowanego ruchu. Ruch może wychodzić na zewnętrznym interfejsie, ale jest blokowany, gdy nadchodzi na interfejsie sieci bezprzewodowej dzięki polityce domyślnego blokowania. Gdy użytkownik potwierdzi swoją tożsamość, jego ruch jest przepuszczany na interfejsie sieci bezprzewodowej i może dotrzeć przez bramkę do pozostałych części sieci. Słowo kluczowe quick jest zastosowane, aby PF nie musiał przetwarzać za każdym razem wszystkich nazwanych zestawów reguł, gdy nowe połączenie przechodzi przez bramkę.

[Wstecz: Problemy z FTP] [Spis treści] [Dalej: Redundantny firewall z CARP i pfsync]


[back] www@openbsd.org
$OpenBSD$