ИМЕ
hosts_access - формат на файловете за контрол на достъп на хост
ОПИСАНИЕ
Тази ръководна страница описва прост език за контрол на достъпа, който се основава на моделите на клиента (име на хост / адрес, потребителско име) и сървър (име на процес, име на хост / адрес). Примери са дадени в края. Нетърпеливият читател се насърчава да премине към секцията EXAMPLES за бързо въвеждане . Една разширена версия на езика за контрол на достъпа е описана в документа hosts_options (5). Разширенията се включват по време на програмиране, като се изгражда с -DPROCESS_OPTIONS.
В следващия текст демонът е процесът на процеса на мрежов демон , а клиентът е името и / или адреса на хост услуга. Имената на процесорите на мрежовия демон са посочени в конфигурационния файл на inetd.
ДОКУМЕНТИ ЗА КОНТРОЛ НА ДОСТЪПА
Софтуерът за контрол на достъпа се консултира с два файла . Търсенето спира при първия мач.
Достъпът ще бъде разрешен, когато двойка (демон, клиент) съответства на запис в файла /etc/hosts.allow .
В противен случай достъпът ще бъде отказан, когато двойка (демон, клиент) съответства на запис в файла /etc/hosts.deny .
В противен случай ще бъде предоставен достъп.
Несъществуващ файл за контрол на достъпа се третира като празен файл. По този начин контролът на достъпа може да бъде изключен, като не се предоставят никакви файлове за контрол на достъпа.
ПРАВИЛА ЗА КОНТРОЛ НА ДОСТЪПА
Всеки файл за управление на достъпа се състои от нула или повече реда текст. Тези линии се обработват по ред на виждане. Търсенето приключва, когато се намери съвпадение.
Номерът на нов ред се игнорира, когато е предхождан от знак за наклонена черта. Това ви позволява да разделите дългите линии, така че те да се редактират по-лесно.
Празните линии или линии, започващи със знак "#", се игнорират. Това ви позволява да вмъквате коментари и празно пространство, така че таблиците да се четат по-лесно.
Всички останали редове трябва да отговарят на следния формат, като нещата между [] са по избор:
daemon_list: клиентски списък [: shell_command]
daemon_list е списък с една или повече имена на процеси на демон (argv [0]) или заместващи символи (виж по-долу).
client_list е списък на едно или повече имена на хостове, адреси на хостове, модели или заместващи символи (вижте по-долу), които ще бъдат съпоставени с името или адреса на хоста на клиента.
По-сложните формуляри daemon @ host и host @ host са обяснени в секциите на шаблоните на крайните точки на сървъра и съответно на търсенията на потребителски имена.
Елементите от списъка трябва да бъдат разделени със зали и / или запетаи.
С изключение на търсенията на мрежата NIS (YP), всички проверки за контрол на достъпа са нечувствителни към буквите.
МОДЕЛИ
Езикът за контрол на достъпа изпълнява следните модели:
Низъм, който започва с "." характер. Името на хоста се съгласува, ако последните компоненти на името му съвпадат със зададения модел. Например, моделът ".tue.nl" съвпада с името на хоста "wzv.win.tue.nl".
Низъм, завършващ със знак "." характер. Адресът на хоста се съгласува, ако първите му цифрови полета съвпадат с дадения низ. Например, моделът "131.155". съответства на адреса на (почти) всеки хост от мрежата на университета в Айндховен (131.155.xx).
Низът, който започва с "@" символ, се третира като NIS (преди това YP) netgroup име. Името на хост се съгласува, ако е хост член на посочената мрежа. Съответствията в мрежата не се поддържат за имена на процеси на демон или за потребителско име на клиент.
Изразът на формата "nnnn / mmmm" се интерпретира като двойка "мрежа / маска". Адресът на хост на IPv4 се съгласува, ако `net 'е равен на буквата AND на адреса и` mask'. Например, моделът net / mask "131.155.72.0/255.255.254.0" съвпада с всеки адрес в диапазона "131.155.72.0" през "131.155.73.255".
Изразът на формуляра "[n: n: n: n: n: n: n: n] / m" се интерпретира като двойка "[net] / prefixlen". Адресът на хост на IPv6 се съгласува, ако "prefixlen" битовете на "net" са равни на битовете "prefixlen" на адреса. Например, моделът [3ffe: 505: 2: 1 ::] / 64 'съвпада с всеки адрес в диапазона `3ffe: 505: 2: 1: FFFF: FFFF: FFFF: FFFF ".
Низът, който започва с "/" символ, се третира като име на файл . Името или адресът на хост се съгласуват, ако съответстват на което и да е име на хост или адрес, посочени в избрания файл. Файловият формат е нула или повече линии с нула или повече име на хост или адреси, разделени с бяло поле. Шаблонът на име на файл може да се използва навсякъде, където може да се използва име на хост или адрес.
Заместващите символи "*" и "?" може да се използва за свързване на имена на хостове или IP адреси . Този метод за съвпадение не може да бъде използван заедно с "съвпадение на мрежата / маска", като съвпадението с името на хоста започва с "." или съвпадение на IP адрес, завършващ със `. '.
заместващи символи
Езикът за контрол на достъпа поддържа изрични заместващи символи:
ВСИЧКО
Универсалният заместващ знак винаги съвпада.
МЕСТЕН
Съчетава всеки хост, чието име не съдържа знак за точки.
НЕИЗВЕСТЕН
Съчетава всеки потребител, чието име е неизвестно и съответства на всеки хост, чието име или адрес са неизвестни. Този модел трябва да се използва внимателно: имената на хостове може да не са достъпни поради проблеми с временния сървър на имена. Мрежовият адрес няма да бъде достъпен, когато софтуерът не може да разбере какъв тип мрежа говори.
известен
Съчетава всеки потребител, чието име е известно, и съответства на всеки хост, чието име и адрес са известни. Този модел трябва да се използва внимателно: имената на хостове може да не са достъпни поради проблеми с временния сървър на имена. Мрежовият адрес няма да бъде достъпен, когато софтуерът не може да разбере какъв тип мрежа говори.
PARANOID
Съответства на всеки хост, чието име не съответства на адреса му. Когато tcpd е изграден с -DPARANOID (режим по подразбиране), той отхвърля заявки от такива клиенти дори преди да разгледа таблиците за контрол на достъпа. Изградете без -DPARANOID, когато искате повече контрол над такива заявки.
ОПЕРАТОРИ
С ИЗКЛЮЧЕНИЕ
Употребата е предназначена за: "list_1 EXCEPT list_2"; тази конструкция съответства на всичко, което съответства на списък_1, освен ако не съответства на списък_2 . Операторът EXCEPT може да се използва в daemon_lists и in client_lists. Операторът EXCEPT може да бъде вложен: ако контролния език позволява използването на скоби, "a EXCEPT b EXCEPT c" ще се анализира като "(EXCEPT (EXCEPT c))".
Ако правилото за контрол на достъпа за първото съвпадение съдържа команда за shell, тази команда се подлага на% замествания (вж. Следващия раздел). Резултатът се изпълнява от a / bin / sh child процес със стандартен вход, изход и грешка, свързан към / dev / null . Посочете "&" в края на командата, ако не искате да изчакате, докато не приключи.
Shell командите не трябва да разчитат на настройката PATH на inetd. Вместо това те трябва да използват абсолютни имена на пътя, или те трябва да започнат с изрично PATH = каквото и да е изявление.
Документът hosts_options (5) описва алтернативен език, който използва командно поле на shell (shell) в различен и несъвместим начин.
% EXPANSIONS
Следните разширения са налични в командите на shell:
% a (% A)
Адрес на хоста на сървъра (сървър).
%° С
Информация за клиента: user @ host, user @ address, име на хост или само адрес, в зависимост от наличната информация.
%д
Името на процеса на демон (argv [0]).
% h (% Н)
Името или адреса на хоста на клиента (сървъра), ако името на хоста не е налице.
% n (% N)
Името на хоста на клиента (сървър) (или "неизвестно" или "параноично").
% р
Процесът на процеса на демона.
%с
Информация за сървъра: daemon @ host, daemon @ address, или само име на демон, в зависимост от наличната информация.
% ф
Потребителското потребителско име (или "неизвестно").
%%
Разширява до един знак "%".
Знаците в% разширения, които могат да объркат черупката, се заменят с долни черти.
СТРАНИЧНИ ЕЛЕКТРИЧЕСКИ МОДЕЛИ
За да разграничите клиентите от мрежовия адрес, към който се свързват, използвайте моделите на формуляра:
process_name @ host_pattern: client_list ...
Моделите като тези могат да се използват, когато машината има различни интернет адреси с различни имена на интернет. Доставчиците на услуги могат да използват това съоръжение, за да предложат FTP, GOPHER или WWW архиви с интернет имена, които дори могат да принадлежат на различни организации. Вижте също опцията `twist 'в документа hosts_options (5). Някои системи (Solaris, FreeBSD) могат да имат повече от един интернет адрес на един физически интерфейс; с други системи може да се наложи да прибягвате до псевдо интерфейси SLIP или PPP, които живеят в специално адресно пространство в мрежата.
Псевдоподдържателят се подчинява на същите правила за синтаксис като имената и адресите на хоста в контекста на client_list. Обикновено информацията за крайната точка на сървъра е налице само при услуги, свързани с връзка.
КЛИЕНТЪТ НА ПОТРЕБИТЕЛЯ
Когато клиентският хост поддържа протокола RFC 931 или един от неговите потомци (TAP, IDENT, RFC 1413), програми за обвиване могат да извлекат допълнителна информация за собственика на връзката. Информацията за потребителското име на клиента, когато е налице, се записва заедно с името на хоста на клиента и може да се използва, за да съответства на модели като:
daemon_list: ... user_pattern @ host_pattern ...
Демонстрационните обвивки могат да бъдат конфигурирани по време на компилиране, за да се изпълнят заявки за потребителски имена, управлявани от правилата (по подразбиране), или винаги да се разпитва клиент-хост. В случай на заявки за потребителски имена, управлявани от правило, горепосоченото правило би довело до търсене на потребителско име само когато съвпадат с daemon_list и match_pattern .
Потребителският модел има същия синтаксис като модела на процеса на демон, така че се прилагат едни и същи заместващи символи (членството в мрежата не се поддържа). Не бива да се пренебрегваме с търсенето на потребителски имена.
Информацията за потребителското име на клиента не може да бъде надеждна, когато е най-необходима, т.е. когато клиентската система е била компрометирана. Като цяло, ALL и (UN) KNOWN са единствените модели на потребителско име, които имат смисъл.
Извличането на потребителски имена е възможно само с TCP-базирани услуги и само когато клиент-домакин изпълнява подходящ демон; във всички останали случаи резултатът е "неизвестен".
Едно добре известно бъг на ядрото на UNIX може да доведе до загуба на услуга, когато търсенето на потребителски имена е блокирано от защитна стена. В документа за обвивка README се описва процедура, за да се установи дали вашето ядро има тази грешка.
Търсене на потребителски номера може да доведе до забележими закъснения за потребители, които не са на UNIX. Времето за изчакване по подразбиране за търсене на потребителски имена е 10 секунди: твърде кратко, за да се справи с бавните мрежи, но достатъчно дълго, за да дразни потребителите на компютъра.
Селективните търсения на потребителски имена могат да облекчат последния проблем. Например правило като:
daemon_list: @pcnetgroup ALL @ ALL
ще съответства на членовете на PC netgroup, без да търси потребителски имена, но ще извърши търсене на потребителско име с всички останали системи.
ОТКРИВАНЕ НА ПОСЛЕДОВАТЕЛНИ ПОВТОРИ НА АДРЕС
Грешка в генератора на последователни номера на много TCP / IP реализации позволява на нарушителите лесно да се представят за надеждни хостове и да се разпаднат, например чрез услугата за отдалечен черупки. Службата IDENT (RFC931 и т.н.) може да се използва за откриване на такива и други атаки срещу спасяване на адреси на хост.
Преди да приемете искането на клиент, опаковките могат да използват услугата IDENT, за да разберат, че клиентът изобщо не е изпратил искането. Когато хостът на клиента предоставя услуга IDENT, резултатът от отрицателното търсене на IDENT (клиентът съвпада с "UNKNOWN @ host") е силно доказателство за атака на компютрите.
Положителният резултат от търсене IDENT (клиентът съвпада с "KNOWN @ host") е по-малко надежден. Възможно е нарушител да пропусне както клиентската връзка, така и търсенето IDENT, въпреки че това е много по-трудно, отколкото да се подправя само клиентска връзка. Възможно е също така сървърът IDENT на клиента да е лъган.
Забележка: Търсенията IDENT не работят с UDP услуги.
ПРИМЕРИ
Езикът е достатъчно гъвкав, че различните видове политики за контрол на достъпа могат да бъдат изразени с минимален шум. Въпреки че езикът използва две таблици за контрол на достъпа, най-често срещаните правила могат да бъдат изпълнени, като една от таблиците е тривиална или дори празна.
При четене на примерите по-долу е важно да се разбере, че таблицата позволи се сканира преди отхвърлянето на таблицата, че търсенето се прекратява, когато се намери съвпадение, и че достъпът се дава, когато не се намери съвпадение.
Примерите използват имена на хостове и домейни. Те могат да бъдат подобрени чрез включване на информация за адрес и / или мрежа / мрежова маска, за да се намали въздействието на неуспешните търсения на сървъра за временни имена.
НАЙ-МНОГО ЗАТВОРЕНО
В този случай достъпът се отказва по подразбиране. Само достъпът до изрично оторизирани хостове е разрешен.
Политиката по подразбиране (без достъп) се изпълнява с тривиален отказ файл:
/etc/hosts.deny: ВСИЧКИ: ВСИЧКИ
Това отхвърля цялата услуга на всички хостове, освен ако им е разрешен достъп чрез записи в разрешения файл.
Изрично упълномощените хостове са изброени в разрешения файл. Например:
/etc/hosts.allow: ВСИЧКИ: LOCAL @some_netgroup
ВСИЧКИ: .foobar.edu С ИЗКЛЮЧЕНИЕ terminalserver.foobar.edu
Първото правило позволява достъп от хостове в локалния домейн (без "." В името на хоста) и от членовете на netgroup some_netgroup . Второто правило позволява достъп от всички хостове в домейна foobar.edu (забележете водещата точка), с изключение на terminalserver.foobar.edu .
ОТВОРЕНО
Тук достъпът се предоставя по подразбиране; само изрично посочените хостове се отказват от услугата.
Политиката по подразбиране (предоставеният достъп) прави резервния файл излишен, така че да може да бъде пропуснат. Изрично неупълномощените хостове са изброени в отказания файл. Например:
/etc/hosts.deny: ВСИЧКИ: some.host.name, .some.domain
ВСИЧКИ ИЗКЛЮЧЕНИ in.fingerd: други.домейни.намейни, .other.domain
Първото правило отрича някои хостове и домейни за всички услуги; второто правило все още позволява заявки за пръстови от други хостове и домейни.
БЪРЗО ГРИЖИ
Следващият пример позволява заявки за tftp от хостове в локалния домейн (забележете водещата точка). Исканията от други хостове са отказани. Вместо искания файл се изпраща сонда за пръста на обиждащия хост. Резултатът се изпраща по пощата на суперпотребителя.
/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 корен) &Командата safe_finger идва с опаковката tcpd и трябва да бъде инсталирана на подходящо място. Ограничава възможните повреди от изпратените от сървъра на отдалечения пръст данни. Тя осигурява по-добра защита от стандартната команда за пръсти.
Разширяването на последователностите% h (хост на клиента) и% d (име на услугата) е описано в секцията за команди на shell.
Предупреждение: не дръпнете дланите на пръста си, освен ако не сте подготвени за безкрайни пръсти на пръстите.
При мрежовите защитни стени този трик може да бъде пренесен още повече. Типичната мрежова защитна стена предоставя само ограничен набор от услуги за външния свят. Всички останали услуги могат да бъдат "подслушвани", точно както в горния пример на TFTP. Резултатът е отлична система за ранно предупреждение.
ВИЖТЕ СЪЩО
tcpd (8) tcp / ip програма за обвиване на демон. tcpdchk (8), tcpdmatch (8), тестови програми.Важно: Използвайте командата човек ( % man ), за да видите как се използва команда на вашия компютър.