Hosts.allow - Linux Command

Imię

hosts_access - format dostępu do hosta Pliki kontrolne systemu Linux.

Opis

Ta strona podręcznika opisuje system Linux jako prosty język kontroli dostępu oparty na wzorcach klienta (nazwa hosta / adres, nazwa użytkownika) i serwer (nazwa procesu, nazwa hosta / adres). Przykłady podano na końcu. Niecierpliwego czytelnika zachęcamy do przejścia do sekcji Przykłady w celu szybkiego wprowadzenia. Rozszerzona wersja języka kontroli dostępu jest opisana w hosts_options (5) dokument. Rozszerzenia są włączane w czasie budowania programu, budując z -DPROCESS_OPTIONS.

W poniższym tekście demon jest nazwą procesu demona sieciowego, oraz klient jest nazwą i / lub adresem hosta żądającego usługi. Nazwy procesów demonów sieciowych są określone w pliku konfiguracyjnym inetd.

Pliki kontroli dostępu

Oprogramowanie kontroli dostępu konsultuje dwa pliki. Wyszukiwanie zatrzymuje się w pierwszym meczu.

Dostęp zostanie przyznany, gdy para (daemon, klient) pasuje do wpisu w /etc/hosts.allow plik.

W przeciwnym razie dostęp zostanie odrzucony, gdy para (daemon, klient) pasuje do wpisu w /etc/hosts.deny plik.

W przeciwnym razie dostęp zostanie przyznany.

Nieistniejący plik kontroli dostępu traktowany jest tak, jakby był pustym plikiem. W ten sposób kontrola dostępu może zostać wyłączona poprzez brak plików kontroli dostępu.

Zasady kontroli dostępu

Każdy plik kontroli dostępu składa się z zero lub więcej linii tekstu. Linie te są przetwarzane w kolejności występowania. Wyszukiwanie kończy się po znalezieniu dopasowania.

Znak nowego wiersza jest ignorowany, gdy poprzedza go lewy ukośnik. Pozwala to na dzielenie długich linii, dzięki czemu łatwiej je edytować.

Puste linie lub linie zaczynające się znakiem `# 'są ignorowane. Pozwala to wstawiać komentarze i białe spacje, aby tabele były łatwiejsze do odczytania.

Wszystkie pozostałe wiersze powinny być zgodne z następującym formatem, przy czym między jest opcjonalne:

daemon_list: lista_klientów : shell_command

daemon_list jest listą jednej lub więcej nazw procesów demona (wartości argv 0) lub symboli wieloznacznych (patrz poniżej).

Lista klientów jest listą co najmniej jednej nazwy hosta, adresu hosta, wzorców lub symboli wieloznacznych (patrz niżej), które zostaną dopasowane do nazwy lub adresu hosta klienta.

Bardziej skomplikowane formy daemon @ host i użytkownik @ host wyjaśnione są odpowiednio w sekcjach dotyczących wzorców punktów końcowych serwerów i wyszukiwania nazw użytkowników klienta.

Elementy listy powinny być oddzielone spacjami i / lub przecinkami.

Z wyjątkiem wyszukiwań grupy NIS (YP), wszystkie kontrole kontroli dostępu nie uwzględniają wielkości liter.

Wzory

Język kontroli dostępu implementuje następujące wzorce:

Ciąg zaczynający się od `. ' postać. Nazwa hosta jest dopasowywana, jeśli ostatnie komponenty jego nazwy pasują do określonego wzorca. Na przykład wzorzec `.tue.nl 'odpowiada nazwie hosta` wzv.win.tue.nl'.

Ciąg kończący się znakiem "." postać. Adres hosta jest dopasowywany, jeśli jego pierwsze pola numeryczne pasują do podanego ciągu. Na przykład wzorzec `131.155. ' pasuje do adresu (prawie) każdego hosta w sieci Uniwersytetu Eindhoven (131.155.x.x).

Łańcuch rozpoczynający się znakiem `@ 'jest traktowany jako nazwa grupy sieciowej NIS (wcześniej YP). Nazwa hosta jest dopasowana, jeśli jest członkiem hosta określonej grupy. Dopasowania Netgroup nie są obsługiwane dla nazw procesów demonów lub dla nazw użytkowników klienta.

Wyrażenie postaci "n.n.n.n.m..m.m" jest interpretowane jako para `net / maska ​​'. Adres IPv4 jest dopasowywany, jeśli "net" jest równe bitowemu AND adresu i "maski". Na przykład wzorzec net / mask "131.155.72.0/255.255.254.0" pasuje do każdego adresu z zakresu od "131.155.72.0" do "131.155.73.255".

Wyrażenie postaci "n: n: n: n: n: n: n: n / m" interpretowane jest jako para "net / prefixlen". Adres hosta IPv6 jest dopasowywany, jeśli `prefixlen 'bity` net' są równe `` prefixlen 'bitom adresu. Na przykład wzorzec net / prefixlen `3ffe: 505: 2: 1 :: / 64 'pasuje do każdego adresu w zakresie` 3ffe: 505: 2: 1 ::' do `3ffe: 505: 2: 1: ffff: ffff: ffff: ffff '.

Łańcuch rozpoczynający się znakiem `/ 'jest traktowany jako nazwa pliku. Nazwa lub adres hosta jest dopasowany, jeśli pasuje do dowolnej nazwy hosta lub wzorca adresu wymienionego we wskazanym pliku. Format pliku wynosi zero lub więcej wierszy z zerową lub większą liczbą nazw hosta lub wzorców adresów rozdzielonych białymi znakami. Wzorzec nazwy pliku może być używany wszędzie tam, gdzie można użyć nazwy hosta lub wzorca adresu.

Symbole wieloznaczne `* 'i`?' można użyć do dopasowania nazw hostów lub adresów IP. Ta metoda dopasowywania nie może być używana w połączeniu z dopasowaniem "net / mask", dopasowaniem nazwy hosta zaczynającym się od `. ' lub adres IP pasujący do ".".

Wildcards

Język kontroli dostępu obsługuje jawne symbole wieloznaczne, w tym:

'WSZYSTKO'

Uniwersalny symbol wieloznaczny zawsze pasuje.

'LOKALNY'

Pasuje do dowolnego hosta, którego nazwa nie zawiera znaku kropki.

'NIEZNANY'

Pasuje do dowolnego użytkownika, którego nazwa jest nieznana, i pasuje do dowolnego hosta, którego nazwę lub adres jest nieznany. Ten wzorzec powinien być używany ostrożnie: nazwy hosta mogą być niedostępne z powodu problemów z tymczasowym serwerem nazw. Adres sieciowy będzie niedostępny, gdy oprogramowanie nie będzie w stanie określić, z jakim typem sieci się komunikuje.

'ZNANY'

Pasuje do dowolnego użytkownika, którego nazwa jest znana, i pasuje do dowolnego hosta, którego nazwę i adres jest znany.Ten wzorzec powinien być używany ostrożnie: nazwy hosta mogą być niedostępne z powodu problemów z tymczasowym serwerem nazw. Adres sieciowy będzie niedostępny, gdy oprogramowanie nie będzie w stanie określić, z jakim typem sieci się komunikuje.

'PARANOIDALNY'

Pasuje do dowolnego hosta, którego nazwa nie jest zgodna z jego adresem. Kiedy tcpd jest zbudowany z -DPARANOID (tryb domyślny), odrzuca żądania od takich klientów, nawet zanim przejrzysz tabele kontroli dostępu. Twórz bez -DPARANOID, jeśli chcesz mieć większą kontrolę nad takimi żądaniami.

"OPERATORZY"

'Z WYJĄTKIEM'

Przeznaczenie ma postać: `list_1 WYJĄĆ list_2 '; ta konstrukcja pasuje do wszystkiego, co pasuje list_1 chyba że pasuje list_2 . Operator EXCEPT może być używany w daemon_lists i na listach client_lists. Operator EXCEPT może być zagnieżdżony: jeśli język kontrolny pozwoliłby na użycie nawiasów, "a EXCEPT b EXCEPT c" byłby analizowany jako `(a EXCEPT (b EXCEPT c)).

Polecenia powłoki

Jeśli pierwsza dopasowana reguła kontroli dostępu zawiera polecenie powłoki, polecenie to zostanie zastąpione% substytucjami (patrz następna sekcja). Wynik jest wykonywany przez / bin / sh proces potomny ze standardowym wejściem, wyjściem i błędem połączony z / dev / null . Określ "&" na końcu polecenia terminalu, jeśli nie chcesz czekać, aż zostanie zakończone.

Polecenia powłoki nie powinny opierać się na ustawieniu PATH inetd. Zamiast tego powinny używać bezwzględnych nazw ścieżek lub powinny zaczynać się od jawnej PATH = jakiejkolwiek instrukcji.

The hosts_options (5) dokument opisuje alternatywny język, który używa pola poleceń powłoki w inny i niekompatybilny sposób.

% Rozszerzeń

Następujące rozszerzenia są dostępne w komendach powłoki:

% a (% A) - Adres hosta klienta (serwera).

%do - Informacje o kliencie: użytkownik @ host, adres @ użytkownika, nazwa hosta lub po prostu adres, w zależności od ilości dostępnych informacji.

%re - Nazwa procesu demona (wartość argv 0).

% h (% H) - Nazwa lub adres hosta (serwera) klienta, jeśli nazwa hosta jest niedostępna.

% n (% N) - Nazwa hosta klienta (serwera) (lub "nieznany" lub "paranoidalny").

% p - Identyfikator procesu demona.

% s - Informacje o serwerze: daemon @ host, daemon @ address lub po prostu nazwa demona, w zależności od ilości dostępnych informacji.

% u - Nazwa użytkownika klienta (lub "nieznany").

%% - Rozszerza się do pojedynczego znaku `% '.

Znaki w% rozszerzeń, które mogą mylić powłokę, są zastępowane przez podkreślenia.

Wzorce punktów końcowych serwerów

Aby odróżnić klientów według adresu sieciowego, z którym się łączą, użyj wzorców formularza:

process_name @ host_pattern: lista_klientów …

Wzorce takie jak te mogą być używane, gdy maszyna ma różne adresy internetowe z różnymi nazwami hostów internetowych. Usługodawcy mogą korzystać z tego narzędzia w celu oferowania archiwów FTP, GOPHER lub WWW z nazwami internetowymi, które mogą należeć nawet do różnych organizacji. Zobacz także opcję `twist 'w dokumencie hosts_options (5). Niektóre systemy (Solaris, FreeBSD) mogą mieć więcej niż jeden adres internetowy w jednym fizycznym interfejsie; w przypadku innych systemów może być konieczne korzystanie z pseudo interfejsów SLIP lub PPP, które znajdują się w dedykowanej przestrzeni adresowej sieci.

Parametr host_pattern jest zgodny z tymi samymi regułami składni, co nazwy i adresy hostów w kontekście listy klienta. Zwykle informacje o punkcie końcowym serwera są dostępne tylko w przypadku usług zorientowanych na połączenie.

Wyszukiwanie nazwy użytkownika klienta

Gdy host klienta obsługuje protokół RFC 931 lub jeden z jego potomków (TAP, IDENT, RFC 1413), programy otoki mogą pobierać dodatkowe informacje o właścicielu połączenia. Informacje o nazwie użytkownika klienta, o ile są dostępne, są rejestrowane razem z nazwą hosta klienta i mogą być używane do dopasowywania wzorców takich jak:

daemon_list: … user_pattern @ host_pattern …

Pakiety demona można skonfigurować podczas kompilacji w celu wykonywania wyszukiwania nazw użytkownika opartych na regułach (domyślnie) lub zawsze przesłuchiwania hosta klienta. W przypadku wyszukiwania nazw użytkowników opartych na regułach, powyższa reguła spowoduje wyszukiwanie nazwy użytkownika tylko wtedy, gdy oba daemon_list i host_pattern mecz.

Wzorzec użytkownika ma taką samą składnię jak wzorzec procesu demona, więc mają zastosowanie te same symbole wieloznaczne (członkostwo w sieci nie jest obsługiwane). Nie należy jednak zaprzątać sobie głowy wyszukiwaniem nazw użytkowników.

Informacji o nazwie użytkownika klienta nie można ufać, gdy jest ona najbardziej potrzebna, tj. Gdy system klienta został przejęty. Ogólnie rzecz biorąc, WSZYSTKIE i (ZNANE) są jedynymi wzorcami nazw użytkowników, które mają sens.

Wyszukiwanie nazw użytkowników jest możliwe tylko w przypadku usług opartych na protokole TCP i tylko wtedy, gdy host klienta uruchomi odpowiedniego demona; we wszystkich pozostałych przypadkach wynik jest "nieznany".

Dobrze znany błąd jądra systemu UNIX może spowodować utratę usług, gdy wyszukiwanie nazw użytkowników jest blokowane przez zaporę. W opakowaniu dokumentu README opisano procedurę sprawdzania, czy w jądrze występuje ten błąd.

Wyszukiwanie nazw użytkowników może powodować zauważalne opóźnienia dla użytkowników spoza UNIX. Domyślny limit czasu dla wyszukiwań nazw użytkowników to 10 sekund: zbyt krótki, aby poradzić sobie z powolnymi sieciami, ale wystarczająco długi, aby podrażnić użytkowników komputerów.

Selektywne wyszukiwanie nazw użytkowników może złagodzić ostatni problem. Na przykład reguła taka jak:daemon_list: @pcnetgroup ALL @ ALL

pasowałoby do członków grupy net pc bez wykonywania wyszukiwania nazw użytkowników, ale wykonywałoby wyszukiwanie nazw użytkowników we wszystkich innych systemach.

Wykrywanie ataków fałszowania adresów

Wada generatora liczb sekwencyjnych wielu implementacji TCP / IP umożliwia intruzom łatwe podszywanie się pod zaufane hosty i włamywanie się przez, na przykład, zdalną usługę powłoki.Usługa IDENT (RFC931 itp.) Może być używana do wykrywania takich i innych ataków fałszowania adresów hostów.

Przed zaakceptowaniem żądania klienta, owijacze mogą korzystać z usługi IDENT, aby dowiedzieć się, że klient w ogóle nie wysłał żądania. Kiedy host klienta dostarcza usługę IDENT, negatywny wynik wyszukiwania IDENT (klient pasuje do `UNKNOWN @ host ') jest mocnym dowodem na atak spoofingu hosta.

Pozytywny wynik wyszukiwania IDENT (klient pasuje do `KNOWN @ host ') jest mniej godny zaufania. Intruz może sfałszować zarówno połączenie klienta, jak i wyszukiwanie IDENT, chociaż jest to znacznie trudniejsze niż podszywanie się pod klienta. Może to również oznaczać, że serwer IDENT klienta kłamie.

Uwaga: Wyszukiwania IDENT nie działają z usługami UDP.

Przykłady

Język jest na tyle elastyczny, że różne rodzaje polityki kontroli dostępu można wyrazić przy minimalnym zamieszaniu. Mimo że język używa dwóch tabel kontroli dostępu, najpowszechniejsze zasady mogą zostać zaimplementowane, przy czym jedna z tabel jest banalna lub nawet pusta.

Podczas czytania poniższych przykładów ważne jest, aby zdać sobie sprawę, że tabela zezwalająca jest skanowana przed tabelą odmowy, że wyszukiwanie kończy się po znalezieniu dopasowania, a dostęp zostaje przyznany, gdy nie znaleziono żadnego dopasowania.

Przykłady używają nazw hosta i domeny. Można je poprawić, wprowadzając informacje o adresie i / lub sieci / masce sieci, aby zmniejszyć wpływ tymczasowych niepowodzeń wyszukiwania nazw serwerów.

Głównie zamknięte

W tym przypadku dostęp jest domyślnie zabroniony. Tylko jawnie autoryzowani gospodarze mają dostęp.

Domyślna polityka (brak dostępu) jest zaimplementowana z trywialnym plikiem odmowy:

/etc/hosts.deny: ALL: ALL

Zaprzecza to całej usłudze dla wszystkich hostów, chyba że dostęp do nich jest dozwolony przez wpisy w pliku zezwolenia.

Wyraźnie autoryzowani gospodarze są wymienieni w pliku zezwolenia. Na przykład:

/etc/hosts.allow: ALL: LOCAL @some_netgroupALL: .foobar.edu Z WYJĄTKIEM terminalserver.foobar.edu

Pierwsza reguła zezwala na dostęp z hostów w domenie lokalnej (bez `. 'W nazwie hosta) i od członków some_netgroup netgroup. Druga reguła zezwala na dostęp ze wszystkich hostów w foobar.edu domena (zwróć uwagę na kropkę wiodącą), z wyjątkiem terminalserver.foobar.edu .

W większości otwarte

Tutaj dostęp jest domyślnie przyznawany; tylko jawnie określone hosty są odrzucane.

Domyślna polityka (przyznany dostęp) sprawia, że ​​plik zezwolenia jest zbędny, więc można go pominąć. Wyraźnie niedozwolone hosty są wymienione w pliku odmowy. Na przykład:

/etc/hosts.deny: ALL: some.host.name, .some.domainALL EXCEPT in.fingerd: other.host.name, .other.domain

Pierwsza reguła odmawia niektórym hostom i domenom wszystkich usług; druga zasada nadal zezwala na żądania od innych hostów i domen.

Pułapki Booby

Następny przykład zezwala na żądania tftp od hostów w domenie lokalnej (zwróć uwagę na kropkę wiodącą). Żądania od innych hostów są odrzucane. Zamiast żądanego pliku sonda palca jest wysyłana do obraźliwego hosta. Wynik jest wysyłany do superużytkownika.

/etc/hosts.allow:

in.tftpd: LOCAL, .my.domain/etc/hosts.deny:in.tftpd: ALL: spawn (/ some / where / safe_finger -l @% h | / usr / ucb / mail -s% d-% h root) &

Polecenie safe_finger jest dostarczane z opakowaniem tcpd i powinno zostać zainstalowane w odpowiednim miejscu. Ogranicza możliwe uszkodzenia z danych wysyłanych przez zdalny serwer finger. Zapewnia lepszą ochronę niż standardowe polecenie palcem.

Rozszerzenie sekwencji% h (hosta klienta) i% d (nazwy usługi) opisano w sekcji poleceń powłoki.

Ostrzeżenie: Nie próbuj pułapki swojego demona palca, chyba że jesteś przygotowany na nieskończone pętle palców.

W sieciowych systemach zapór ogniowych ta sztuczka może być przenoszona jeszcze dalej. Typowa zapora sieciowa zapewnia ograniczony zestaw usług dla świata zewnętrznego. Wszystkie inne usługi mogą być "błędne", podobnie jak powyższy przykład tftp. Rezultatem jest doskonały system wczesnego ostrzegania.

Zobacz też

Program otoki tcpd (8) tcp / ip demona.tcpdchk (8), tcpdmatch (8), programy testowe.

Ważny: Użyj mężczyzna dowództwo ( % mężczyzna ), aby zobaczyć, jak polecenie jest używane na danym komputerze.