9.10 Установление подлинности с PPP.10.1 CHAP против PAP
С PPP, каждая система может требовать, чтобы peer опознал себя
используя однин из двух опознавательных протоколов. Они - (PAP), и
(CHAP). Когда связь установлена, каждый может запросить другой, чтобы
опознать себя, независимо от того, является ли это caller или callee. Ниже
я буду говорить о "клиенте " и " сервере " когда я захочу сделать различие
между системой опознания и authenticator. PPP daemon может спрашивать
peer отно подлинности, посылая однако другой LCP запрос конфигурации,
опознавающий желаемый протокол.
PAP в основном работает в том же самом способ как нормальная
процедура входа в систему. Клиент опознает себя, посылая имя пользователя и
пароль ксерверу, который сравнивается с базой данных секретов. Этот
метод легкоуязвим к eavesdroppers, который может попытаться получить
пароль, слушая последовательную линию, и к повторению испытания и решения
ошибки.
CHAP не имеет этих недостатков. С CHAP, authenticator (то
есть сервер) посылает беспорядочно сгенерированную " challenge''
строку к клиенту, наряду с hostname. Клиент использует hostname для
того, чтобы искать соответствующий шифр, объединяя это с challenge, и
шифруя строку, используя однонаправленную hashing function. Результат
будет возвращен на сервер наряду с hostname клиента. Сервер теперь
выполняет то же самое вычисление, и подтверждает клиента.
Другая особенность CHAP - то, что он не требуется опознания клиента
для опознания самого себя при запуске, но посылает challenges в
определенные промежутки времени, чтобы удостовериться не был клиент
заменен "злоумяшлепником ", например, только переключая телефонные
линии.
Pppd хранит секретные ключи для CHAP и PAP в двух отдельных
файлах, вназываемых /etc/ppp/chap-secrets и pap-secrets соответственно.
Входом отдаленного хоста в один или другой файл, Вы имеете хороший контроль
над CHAP или PAP предназначенный для этого, чтобы опознать нас с нашим
peer, и наоборот.
По умолчанию, pppd не требует установления подлинности от remote,
но соглашается опознавать себя когда запрошено remote. Так как CHAP
намного более сильна чем PAP, pppd пробует использовать вышеупомянутый
всякий раз, когда это возможно. Если peer этого не поддерживает, или если
pppd не может найти CHAP шифр для remote системы в файле шифров chap, он
возвращается к PAP. Если он имеет PAP шифр для peer также, то он
откажется опознавать в целом, и как следствие, связь закроется.
Это поведение может быть изменено отдельными способами. Например,
когда дается auth ключевое слово, pppd требует, чтобы peer опознал сам
себя. Pppd согласится использовать или CHAP или PAP для этого, как только
это будет имеет шифр для peer в CHAP или в базе данных PAP
соответственно. Имеются другие опции, чтобы включить или выключить
частный опознавательный протокол, но я не буду описывать их здесь.
Пожалуйста обратитесь к pppd (8) для деталей.
Если все системы, с которыми Вы говорите PPP, соглашаются опознавать
самих себя с Вами, Вы должны поместить опцию auth в глобальный
файл /etc/ppp/options и определить пароли для каждой системы в файле
шифров chap. Если система не поддерживает CHAP, добавьте запись к файлу
pap шифров. Таким образом, Вы можете удостовериться в том, что никакая
неопознанная система не соединяется с Вашим хостом.
Следующие два раздела обсуждают два PPP файла шифров, pap-
secrets и chap-secrets. Они размещзны "в /etc/ppp и содержат тройки
клиентуры, серверов и паролей, необязательно сопровождаемых списком из
адресов IP. Интерпретация клиента и областей сервера отлична для CHAP или
PAP, и также зависит от того, опознаем ли мы себя самостоятельно с peer,
или потребуем опознать сервер непосредственно с нами.
9.10.2 Файл шифров CHAP
Когда это должно опознать себя с некоторым сервером, используя CHAP,
рppd ищет файл шифров PAP для записи с клиентской областью равной
локальному hostname, и области сервера равной к remote hostname
посланный в CHAP Challenge. При требовании peer к опознаванию себя, роли
просто поменялись: pppd будет затем искать запись с клиентской
областью приравненной к отдаленному hostname (посланный в CHAP ответ
клиенту) и область сервера приравненной локальному хосту.
Следующее - типовой файл шифров chap для vlager: (9)
# CHAP secrets for vlager.vbrew.com
#
# client server secret addrs
#-------------------------------------------------------------------
---
vlager.vbrew.com c3po.lucas.com "Use The Source Luke"
vlager.vbrew.com
c3po.lucas.com vlager.vbrew.com "riverrun, pasteve"
c3po.lucas.com
* vlager.vbrew.com "VeryStupidPassword"
pub.vbrew.com
При установлении PPP связи с c3po, c3po запрашивает vlager опознать
себя, используя CHAP, посылая CHAP challenge. Pppd затем просматривает chap
шифры для записи с клиентской областью, приравненой к vlager.vbrew.com и
областью сервера приравненной к c3po.lucas.com, (10) и находит
первую линию, показанную выше. Затем производится CHAP ответ от challenge
string и шифра (Используйте Источник Luke), и посылает от c3po.
В то же самое время, pppd составляет CHAP challenge для c3po,
содержащую уникальную challenge string, и пплноутью квалифицированный
hostname vlager.vbrew.com. C3po создает CHAP ответ способом, который мы
только что обсудили, и возвращает это к vlager. Pppd теперь извлекает
клиентский hostname (c3po.vbrew.com) из ответа, и поисков файлов шифра chap
для линии, соответствующей c3po как клиент, и vlager как сервер. Вторая
линия делает так что pppd объединяет CHAP challe pasteve, шифрует их,
и сравнивает результат с с3po CHAР ответа.
Произвольная четвертая область перечисляет адреса IP, которые
являются для клиентуры, именованной в первой области. Адреса могут быть
даны в dotted quad notation или как hostnames, которые разысксканы с
помощью решающего устройства. Например, если запрос c3po, на использование
IP адреса во время IPCP переговора, который не в этом списке, запрос будет
отклонен, и IPCP будет выключено. В типовойфайле, показанном выше, с3po
следовательно будет ограничен использованием собств Если область адреса
пуста, любые адреса будут позволяться, значение которых -
предотвращает использование IP с клиентом.
Третья линия в примере файле шифров chap позволяет любому хосту
установить связь PPP с vlager потому что клиент или область сервера
соответствует hostname. Единственое требование - то, что он знает пароль,
и использует адрес pub.vbrew.com. Вход с групповым символом hostnames
может появится где-нибудь в файле шифров, так как pppd будет всегда
использовать наиболее специфическую запись, которая применяется к паре
сервера / клиента.
9. Двойные кавычки - не часть пароля, они просто служат для того,
чтобы защитить незаполненное пространство внутри пароля.
10. Этот hostname принимается из CHAP challenge.
Имеются некоторые слова, которые нужно упоминуть относительно
способа, которым pppd достигает hostnames: он ищет в файле шифров.
Как было объяснено прежде, отдаленный hostncme всегда обеспечивается
peer в CHAP Challenge или в Response packet. Локальный hostname будет
получен, если вызвать gethostname функцию (2) по умолчанию. Если Вы
установили название системы Вашему неквалифицированному hostname, то Вы
должны обеспечить его pppd областью.
# pppd ...domain vbrew.com
Это конкатенирует название Brewery области к vlager для всех
установленых подлинностью действия. Другие опции, которые модифицируют
progpppd's idea относительно локального hostname - usehostname и name.
Когда Вы даете локальный IP адрес на командной строке, использующей
"local:varremote", и local - название вместо dotted quad, pppd
использует это как локальный hostname. Для деталей, пожалуйста
обратитеськ pppd странице справочника (8).
9.10.3 Файл шифров PAP.
Файл шифров PAP очень похожа на тот, который используется CHAP.
Сначала две области всегда содержат название пользователя и название
сервера; третья часть задерживает шифр PAP. Когда remote посылает
опознающийся запрос, рppd использует запись, которая имеет область
сервера равной локальному hostname, и область пользователя
приравненной к имени пользователя, посланному в запросе. Когда
опознание себя с peer произойдет, pppd выберет шифр, который будет послан
из линии с область приравненной к локальному имени пользователя, и
областью сервера приравненной к remote hostname.
Типовой файл шифров PAP мог бы выглядить следующим образом:
# /etc/ppp/pap-secrets
#
# user server secret addrs
vlager-pap c3po cresspahl vlager.vbrew.com
c3po vlager DonaldGNUth c3po.lucas.com
Первая линия используется для того, чтобы опознать нас когда мы
говорим с с3ро.
Вторая линия описывает, как пользователь именнованняй c3po, должен
быть опознаным непосредственно с нами.
Имя vlager-pap в столбце, который является именем пользователя, мы
посылаем к c3po. По умолчанию, pppd выберет локальный hostname как имя
пользователя, но Вы можете также определить различные названия, давая опцию
пользователя, сопровождаемую эти именем.
При выборе записи из файла шифров PAP регистрируются для
установления подлинности с peer, pppd должен знать название remote хоста.
Поскольку это не имеет способа нахождения того, что Вы должны точно
определить на этой командной строке, используяе remotename ключевого
слова, сопровождаемого hostname peer. Для образца, как использовать
вышеупомянутую запись для установления подлинности с c3po, мы добавляем
опцию следования к командной строке pppd's:
\#{} pppd ... remotename c3po user vlager-pap
В четвертой области (и все следующие области), Вы можете точно
определить какие адреса IP разрешены для того частного множества, точно как
и в файле шифров CHAP. Peer может затем только запроситьь адреса из этого
списка. В типовом файле, мы требуем, чтобы c3po использовал реальный адрес
IP.
Заметьте, что PAP довольно слабый опознавательный метод, и это
предполагает всякий раз, когда Вы используете CHAP, если это возможно.
Мы не будем следовательно описывать PAP в деталях здесь; если Вы
заинтересованы в использовании PAP, Вы найдете несколько больше в pppd
странице справочника (8).
9.11 Конфигурирование PPP сервера
При запуске pppd, поскольку сервер - только сущность
добавления соответствующей опции к командной строке. Было бы
идеальным, если Вы создали бы специальный account, скажем ppp, и
дадите этому script или программе как оболочке входа в систему,
которая вызывает pppd с этими опциями. Например, Вы бы добавили
следующую линия к /etc/passwd:
"
ppp:*:500:200:Public PPP Account:/tmp:/etc/ppp/ppplogin
Конечно, Вы можете захотеть использовать более
универсальные uids и gids чем те, что показанны выше. Вы также были бы
должны установить пароль для вышеупомянутого account, использующего команду
passwd.
Ppplogin script может быть выглядить следующим образом:
#!/bin/sh
# ppplogin - script to fire up pppd on login
mesg n
stty -echo
exec pppd -detach silent modem crtscts
Команда mesg блокирует других пользователей, чтобы записать к
tty, используя, на пример, команду записи. Команда stty выключает
знако-отображение на экране. Это необходимо, потому что иначе peer все
посылал бы используя отображение на экране. Наиболее важная опция pppd,
данная выше -detach, потому что это предотвращает pppd от отсоединения
из управления tty. Если мы не точно определим эту опцию, это будет идти
к предпосылке, создания shell script exit. Это было к зависанию. Silent
опция заставляет pppd ждать, пока он не получит блок от системы вызова
прежде, чем это начинает посылать. Это предотвращает от блокировки
по времени, когда система вызова медлена в обслуживании PPP наблюдать
DTR линию, чтобы видеть, понизил ли peer связь, и crtscts включает
аппаратное рукопожатие.
Помимо этих опций, Вы могли бы захотеть вынудить некоторый вид
опознания, например, точно определяя auth на командной строке pppd's, или в
глобальном файле опций. Руководство также обсуждает более специфические
опции для вкл. или выкл. индивидуальных опознавательных протоколов.
10. Различные сетевые приложения
После успешной установки IP и решающего устройства, Вы должны
обратиться к услугам обеспечивающим хорошую работу над сетью. Глава
начинается с конфигурачия пескольких простых сетевых приложений, включая
Inetd сервер, и программы из rlogin совокупности. Незначительная
процедура обращения связывает, с помощью интерфейса, эти услуги
подобно Сетевой Файловой системе (NFS). Сетевая Информационная Система
(NIS) основана на том же самом, имела дело с briefly. Конфигурация NFS
и NIS, однако берущяя большое количество памяти, будет описана в отдельных
главах. Это применяется к электронной почте и netnews также.
Конечно, мы не можем описать все сетевые приложения в этой книге.
Если Вы хотите устанавить то, которое не обсуждается здесь, подобно
переговорам, gopher, или xmosaic пожалуйста обратитесь к руководству для
деталей.
10.1 Inetd супер-сервер
Часто, услуги предоставляются так называемыми daemons. Daemon
является программой, которая открывает некоторый порт, и связь. Если это
происходит, это создает дочерний процесс, который принимает связь, в то
время как основной продолжает ждать дальнейших запросов. Это понятие имеет
недостаток что для каждого предлагаемого обслуживания, daemon должен
запускать те, которые слушают порте для связи, для которых это вообще
означает потери способов системы подобно пространст
Таким образом, почти вся Un*x инсталляция запускает " супер-
сервер ", который создает гнезда для ряда услуг, и слушает на них
одновременно при использовании отобранного системного вызова (2).
Когда отдаленный хост запрашивает одну из услуг, супер-сервер замечает
этот и порождает другой сервер, точно установленный для этого порта.
Супер-сервер, обычно используемый - inetd, Internet Daemon. Это
начинается при начальной загрузке системы, и берет список услуг, к
которым он обращается из файла запуска, именованной /etc/inetd.conf. В
дополнение к тем вызываемым серверам, там есть ряд тривиальных услуг,
которые являются на сформировавшимся inetd, неппсрежственно вызываемым
внутренние услуги. Они включают chargen который просто генерирует ряд
знаков, и daytime который возвращают system's idea
Запись в этой картотеке состоит из единственной линии,
сделанной из следующей области:
service type protocol wait user server cmdline
Значение каждой области следующие:
Service дает сервисное имя. Service name должно быть переведено к
номеру порта, просматривая в файле services. Этот файл будет описан в
разделе 10.3.
type определяет тип гнезда, любой поток (для связь-
ориентируемых протоколов) или dgram (для датаграмных протоколов). TCP
основанна на услугах, которые должны всегда использовать поток, в
то время как UDP-основанные услуги должны всегда использовать dgram.
Protocol называется протоколом переноса, используемым
обслуживанием. Это должно быть подходящим названием протокола, найденное в
файле протоколов, также объяснено ниже.
wait эта опция применяется только на dgram гнездах. Это может быть
также wait или nowait. Если wait определен, то inetd только выполнит один
сервер для точно установленного порта в любое время. Иначе, это
немедленно продолжит слушать на порте после извлечения сервера.
Это полезно для "единственно - связнных " серверов, которые
читают все входящие датаграммы, и затем выходят. Большинство RPC серверов
имеет этот тип и должны следовательно точно определить wait.
Противоположный тип, "многопоточные " серверы, позволяет безграничному
числу образцов, чтобы быть запущенными одновременно; но это редко когда
используется. Эти серверы должны точно определить nowait.
Гнезда потока должны всегда использовать nowait.
User это является идентичностью входа в систему пользователя,
объясненный ниже. Это будет часто root user, но некотпрые" услуги могут
использовать различные account. Это - очень хорошая идея к
применению принципа наименьшего количества привилегии здесь, который
заявляет что Вы не должны запускать команду ниже привилегированного
account если программа не требует этого для присущего функционирования. Для
примера, NNTP сервер новостей будет запускать новости, пока ус риск
защиты (типа tftp, или finger) будут управляться как nobody.
server дает полный путь программы сервера, которая будет выполнена.
cmdline это- командная строка, которую нужно запустить на
сервере. Она включает аргумент 0, который является названием команды.
Обычно, это не будет названием программы сервера, если программа ведет
себя по-другому, когда вызывается с различным именем.
Эта область пуста для внутренних услуг.
Типовой inetd.conf файл изображен на рисунке 10.1. Finger
service прокомментированног так чтобы это было не доступно. Это часто
выполняется из соображений безопасности, потому что может использоваться
нападавшими для того, чтобы получить имя пользовател и на вашей системе.
Tftp имзображено прокомментированным также. Tftp осуществляет
Примитивный Протокол Передачи файла, который позволяет передавать любые
всемирно - читаемые файлы из вашей системы без пароля. Это особенно вредно
для файла /etc/passwd, даже более того, когда Вы не используйте теневой
пароль.
TFTP обычно используется клиентурой без диска и X терминалами при
загрузке их кода из сервера при начальной загрузке. Если Вы должны
запустить tftpd для этой проблемы, удостоверитесь, что ограниченная
область действия к директориям клиентов будет восстановлена из файлов,
добавляя те названия каталогов к команде tftpd's линии. Это показано во
второй tftp линии в примере.
10.2 Tcpd средства управления доступом
"
Начиная с открытия компьютера к сети средство вовлекает много
защиты, приложения разработанные так, чтобы принять меры против типов
решения. Некоторые из этих, однако, могут быть flawed (наиболее
решительно демонстрированными RTM Internet worm), или могут не
различаться между безопасными хостами, из которых просьбы о частном
обслуживании будут приняты, и опасными хостами, чьи запросы должны быть
отклонены. Мы уже кратко обсуждали finger и tftp услуги выше.
#
# inetd services
ftp stream tcp nowait root /usr/sbin/ftpd in.ftpd -l
telnet stream tcp nowait root /usr/sbin/telnetd in.telnetd -
b/etc/issue
#finger stream tcp nowait bin /usr/sbin/fingerd in.fingerd
#tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd
#tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd
/boot/diskless
login stream tcp nowait root /usr/sbin/rlogind in.rlogind
shell stream tcp nowait root /usr/sbin/rshd in.rshd
exec stream tcp nowait root /usr/sbin/rexecd in.rexecd
#
# inetd internal services
#
daytime stream tcp nowait root internal
daytime dgram udp nowait root internal
time stream tcp nowait root internal
time dgram udp nowait root internal
echo stream tcp nowait root internal
echo dgram udp nowait root internal
discard stream tcp nowait root internal
discard dgram udp nowait root internal
chargen stream tcp nowait root internal
chargen dgram udp nowait root internal
Рис. 15. /etc/inetd.conf file.
ограничить доступ к этим услугам " доверенные множества " только,
которые невозможны с обычной установкой, где inetd обеспечивает эту
защиту всей клиентуре.
&Полззное средство для этого - tcpd, (1), так называемый daemon
wrapper. Для ТСP услуги Вы хотите проконтролировать или защищать его,
вызывая вместо его программу сервера. Tcpd регестрирует запрос к syslog
daemon, проверяя позволяют ли remote хосту использовать обслуживание, и
только если это будет выполнено в реальной программе сервера. Заметьте,
что это не работа с udp-основанными услугами.
Например, чтобы перенести finger daemon, Вы должны изменить
corresponding линию в inetd.conf
1. Написано Wietse Venema, wietse@wzv.win.tue.nl.
# wrap finger daemon
finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
Без добавления какого-либо access контроля, это появится у клиенту
точно также как и обычная установка finger, за исключением того, что
любые запросы будут регистрироваться к syslog's auth facility.
Управление доступом выполнено посредством двух файлов,
называемых /etc/hosts.allow и /etc/hosts.deny. Они содержат разрешение
входов и отрицание доступа, соответственно, к некоторым услугам и хостам.
Когда tcpd обрабатывает просьбу о обслуживании finger от
клиентского хоста, именованного Biff.foobar.com, он просматривает
hosts.allow и hosts.deny (в этом порядке) для соответствующей записи и
сервисного и клиентского хоста. Если запись соответствия была найдена в
тся, независимо от любой записи в hosts.deny. Если соответствие
найдено в hosts.deny, то запрос будет отклонен закрывая связь.схему.
Если никакое соответствие не найдено вообще, запрос будет принят.
Входы в файл доступа выглядят следующим образом:
Servicelist: hostlist [: shellcmd]
Servicelist - список сервисных имен из /etc/services, или ключевое
слово ALL. Чтобы соответствовать всем услугам за исключением finger и
tftp, используйте "ALL"EXCGPT finger, tftp''.
Hostlist - список имен хостов или адресов IP, или ключевых слов ALL,
LOCAL, или UNKNOWN. ALL соответствует любой хост, в то время как
LOCAL соответствует имя хоста, не содержащие точку.(2) UNKNOWN
соответствует любым множествам чьи названия или адреса ошибочны.
Name string, начинающееся с точки соответствует всем хостам, чьи
области является равными этому названию. Например,.foobar.com пара -
Biff.foobar.com. Имеются также условия для IP сетевых адресов и
подсет к странице справочника (5) для деталей.
Для того, чтобы отказать в доступе к finger и tftp услугам, кроме
локальных хостов, поместите следующее в /etc/hosts.deny, и сделайте
пустым /etc/hosts.allow:
2. Обычно только локальные имена хостов, полученные из поисков в
/etc/hosts не содержать никакой точки.
in.tftpd, in.fingerd: ALL EXCEPT LOCAL, .your.domain
Произвольная shellcmd область может содержать командную оболочку,
чтобыбыть вызванной, когда запись согласована. Это полезно установить
ловушку, которая может разоблачить потенциальных нападавших:
in.ftpd: ALL EXCEPT LOCAL, .vbrew.com : \
echo "request from %d@%h" >> /var/log/finger.log; \
if [ %h != "vlager.vbrew.com" ]; then \
finger -l @%h >> /var/log/finger.lы отличны.
Область псевдонимов позволяет точно определить альтернативные имена
для того же самого обслуживания.
Обычно, Вы не должны менять файл услуг, который приходит
Наряду с сетевым программным обеспечением на вашей Linux системе.
Однако, мы даем малую выборку из того файла ниже.
# The services file:
#
# well-known services
echo 7/tcp # Echo
echo 7/udp #
discard 9/tcp sink null # Discard
discard 9/udp sink null #
daytime 13/tcp # Daytime
daytime 13/udp #
chargen 19/tcp ttytst source # Character Generator
chargen 19/udp ttytst source #
ftp-data 20/tcp # File Transfer Protocol (Data)
ftp 21/tcp # File Transfer Protocol
(Control)
telnet 23/tcp # Virtual Terminal Protocol
smtp 25/tcp # Simple Mail Transfer Protocol
nntp 119/tcp readnews # Network News Transfer
Protocol
#
# UNIX services
exec 512/tcp # BSD rexecd
biff 512/udp comsat # mail notification
login 513/tcp # remote login
who 513/udp whod " # remote who and uptime
shell 514/tcp cmd # remote command, no passwd
used
syslog 514/udp # remote system logging
printer 515/tcp spooler # remote print spooling
route 520/udp router routed # routing information protocol
Заметьте, что, например, обслуживание ECHO предлагается на порте
7 для обоих и TCP и UDP, и этот порт 512 используется для двух различных
услуг, а именно для СИСТЕМЫ СПУТНИКОВОЙ СВЯЗИ КОМСАТ daemon (которые
сообщают пользователям относительно новой почты, смотри xbiff(1x)), над
UDP, и для remote execution (rexec(1)), используя TCP.
#
# Internet (IP) protocols
#
ip 0 IP # internet protocol, pseudo protocol
number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # internet group multicast protocol
tcp 6 TCP # transmission control protocol
udp 17 UDP # user datagram protocol
raw 255 RAW # RAW IP interface
10.4 Дистанционное управление
Очень общий механизм для клиент-сервера приложения обеспечивается
RPC, пакетом дистанционного управления. RPC был разработан Sun
Micrsystems, и эта система - набор инструментальных средств и библиотечных
функций. Важные приложения, сформированны на вершине RPC - NFS, Network
Filesystem, и NIS, Network Information System, обе из которых будут
представлены в следующих главах.
RPC сервер состоит из системы процедур того, что клиент может
обратится, посылая RPC запрос к серверу, наряду с параметрами
процедуры. Сервер вызовет обозначенную процедуру по защите клиента,
вручая обратно возвращаемое значение, если имеется любое. Чтобы быть
машинно-независимыми, зсе жанные, обмененные между клиентом и сервером
преобразованны к так называемому Внешнему Представлению Данных
(XDR) отправителю, и преобразованны обратно к машинно - локальному
Иногда, уточнения к RPC приложению вводят несовместимые
изменения в процедуре call interface. Конечно, при простом изменение
сервер разрушил бы все приложение, которые все еще ожидают original
behavior. Следовательно, RPC программы имеют номера версии, приписываемые
к ним, обычно начинающийся с 1, и с каждой новой версией RPC свяжит с
помощью интерфейса этот счетчик. Часто, сервер может предлагать несколько
версий одновременно; клиентура затем указывает номером версии версии они
хотят использовать.
Сетевая связь между RPC серверами и клиентурой - особая. RPC
сервер предлагает один или более системных процедур; каждое множество
называется программой, и однозначно идентифицировано номером
программы. Имена обслуживания отбора списка существуют для того,
чтобы запрограммировать числа обычно сохраняемые в /etc/rpc, выборка
которого воспроизведена ниже ра рисунке 10.4
В TCP/IP сетях, перед авторами RPC стояла задача программирования
чисел к обобщенным сетевым услугам. Они выбрали - иметь каждый
сервер, обеспечивающий, и TCP и UDP порт для каждой программы и каждой
версии. Вообще, RPC приложения используют UDP посылку данных, и
возвращаются обратно к TCP тогда, когда данные, которые будут переданы не
впишутся в единственную UDP датаграмму.
Конечно, клиентские программы должны иметь способ выяснить который
из них порт отображения номера программы. Использование файла
конфигурации для этого, был бы слишком негибки; с тех пор RPC
приложения не используют зарезервированные порты, не имеется никакой
гарантии, что порт первоначально подразумевал использоваться наше
приложепие "баз данных. Следовательно, RPC приложения выбирают любой
порт который, они могут получить, и зарегистрировать это с так
называемым por действия - как обслуживание broker для всех RPC
серверов, выполняющиеся на машине: клиент, который хочет войти в контакт с
обслуживанием с данным номером программы сначала сделает запрос
portmapper на числа порта обслуживание, которые могут быть достигнуты.
Этот метод имеет частичный недостаток, что это вводит единственную
точку отказа, очень похожую на inetd daemon. Однако, этот случай немного
хуже, потому что когда portmapper умирает, вся RPC информация порта
теряется; это обычно значит, что Вы должны перезапустить все RPC серверы
вручную, или перезагрузить целую машину.
На Linux, portmapper называется rpc.portmap и постоянно
находится в /usr/sbin. Кроме уверения того, что это начато из rc.inet2,
рortmapper не требует любой работы по конфигурации.
10.5 Конфигурирование r команд
Имеется ряд команд для выполнения команд на remote хосте. Они -
rlogin, rsh, rcp и rcmd. Они все порождают оболочку на remote хосте и
позволяют пользователю выполнять команды. Конечно, клиент должен иметь
account на хосте, где команда должна быть выполнена. Таким образом все
эти команды выполняют процедуру разрешения. Обычно, клиент сообщяет
название входа в систему пользователя на сервер, который
#
# /etc/rpc - miscellaenous RPC-based services
#
portmapper 100000 portmap sunrpc
rstatd 100001 rstat rstat svc rup perfmeter
rusersd 100002 rusers
nfs 100003 nfsprog
ypserv 100004 ypprog
mountd 100005 mount showmount
ypbind 100007
walld 100008 rwall shutdown
yppasswdd 100009 yppasswd
bootparam 100026
" ypupdated 100028 ypupdate
Рис. 16. A sample /etc/rpc file.
по очереди запрашивает пароль, который утвержден обычным способом.
Иногда, однако, желательно ослабить проверки разрешения для
некоторых пользователей. Например, если Вы часто должны регистрироваться
в других машинах на вашей локальной вычислительной сети, Вы могли бы
захотеть быть признанным без ввода пароля каждый раз.
Отключение разрешения желательно только на малом числе хостов, чьи
базы данных паролей синхронизированы, или для малого числа из
привилегированных пользователей, которые должны обращаться к
многим машинам для административной причины. Всякий раз, когда Вы
хотите позволять людям регестрироваться на вашем хосте при
необходимости точно определить идентичность входа в систему или пароль,
удостоверитесь, что Вы не делаете ошибку предоставляя доступ кому-нибудь
еще.
Имеются два способа блокировать разрешение, для того чтобы проверить
r команды. Каждый - для супер пользователя, чтобы позволить
некоторым или всем пользователям зарегестрироваться без пароля. Этот
доступ управляется картотекой вызываемой /etc/hosts.equiv. Это содержит
список множеств и имен пользователя, которые рассматриваются
эквивалентными пользователям на локальном хосте. Альтернативная опция -
для пользователя - предоставление другим пользователям на некоторых х
быть перечислены в файле.rhosts в директории пользователя. Для
соображений безопасности, эта картотека должна принадлежать пользователю
или супер пользователю, и не должна быть symbolic link, иначе это будет
игнорирован
Когда клиент запрашивает r обслуживание, ее хост и название
пользователя ищются в файле /etc/hosts.equiv, и затем в файле.rhosts
пользователя. Как - пример, предположим, что janet работает "
гауссе и пытается зарегестрироваться в joe's account на euler. Следуя
далее, мы обратимся к Janet как клиентскому пользователю, и к Joe как к
Локальному пользователю.
Теперь, когда типы Janet
$ Rlogin -l joe euler
на гауссе, сервер сначала проверил бы hosts.equiv (4),
предоставлен ли Janet свободный доступ, и если нет, то он попробует
просмотреть.Rhosts в исходном каталоге joe's.
Файл hosts.equiv на euler походит на это:
gauss
euler
-public
quark.physics.groucho.edu andres
Запись состоит из названия хоста, необязательно сопровождаемого
именем пользователем. Если название множества появляется везде, то
все пользователи от того множества будут допущены к их локальным acount
без любых проверок. В вышеизложенном примере, Janet позволили
бы зарегестрироваться в ее account janet когда выходит из гаусса, и тот
же самый применяется любому другому пользователю за исключением root
Однако, если Janet захочет зарегестрироваться как joe , пароля как обычно.
Если название хоста сопровождается названием пользователя, как
и в последней линии вышеупомянутой типовой картотеки, то этому
пользователю будет дан пароль-свободный доступ ко всем accont за
исключением accony\t root.
Имени хоста может также предшествовать знак "минус", как на
записи "-общий". Это требует разрешения на все account на общем,
независимо от того, что пользователи единичного права предоставляют в их
картотеке.rhosts.
3. В NFS среде окружения, Вы были бы должны дать этому защиту 444,
потому что супер пользователь часто ограничивает в доступе к файлам на
дисках, установленных через NFS.
4. Заметить, что файл hosts.equiv не обыскан когда кто -то делает
попытку к регистрации как root.
Форматфайла.rhosts идентичен таковому hosts.equiv, но значение
немного отлично. Рассмотрите Joe's.rhosts файл на Euler:
chomp.cs.groucho.edu
gauss janet
Первая запись допускает, что joe освобождают acess при
регистрации из Chomp.cs.groucho.edu, но не воздействуют на права любого
другого account на euler или chomp. Вторая запись - небольшое изменение
этого, в котором предоставляется janet свободный доступ к account Joe
при регистрации из гаусса.
Заметьте, что название хоста клиента получено обратным отбором.
Адрес вызывающего оператора к названию, так, чтобы эта особенность
failed с хостами к решающему устройству. Имя хоста клиента
рассматривается в соответствии с названим в хостах зарегистри рованных в
одном из следующих случаев:
+ Каноническиое имя хоста клиента (не псевдоним) буквально
соответствует имени хоста в файле.
+ Если имя хоста клиента - полностью квалифицированно, то название
области (типа возвращенного решающим устройством, когда Вы имеете
выполняющую DNS), не соответствует имени хоста в множествах файлов, это
сравнивается с тем именем хоста, расширенным с локальным названием
области.
11. Сетевая информационная система
Когда Вы запускаете локальную вычислительную сеть, ваша цель -
обеспечить среду окружения вашим пользователям, которая делает сеть
очевидной. Важен stepping stone к этому концу должен хранить
насущными данные типа пользователя синхронизированные между всеми
множествами. Мы видели перед этим, что для решенияимени хоста, мощное и
сложное обслуживание существует, являющееся DNS. Для других задачи, имеется
нет такого специализированного обслуживания. Кроме того, если В малой
локальной вычислительной сетью с no Internet activity, устанавливая DNS
может показаться утояыим затруднение для многих администраторов.
Это - то, почему Sun разрабатывало NIS, Сетевую Информационную
Систему. NIS обеспечивает обобщенные средства доступа к базе данных,
которые могут использоваться для дизинформации данных типа этого,
содержали в passwd и группах файлах всех множествах на вашей сети. Это
заставит сеть появиться только как единственная система, с теми
же самыми account на всех множествах. В подобном режиме, Вы может
использовать NIS, чтобы распределить hostname информационную форму
/etc/hos сети.
NIS основан на RPC, и включает сервер, client-side библиотеку, и
несколько административных инструментальных средств. Первоначально, NIS
назывался Желтые Страницы, или YP, который все еще широко
используется, чтобы неофициально обратиться к этой услуге. С другой
стороны, Желтые Страницы - марка изготовителя Британской Телесвязи,
которая требует от Sun убрать то название. Поскольку вещи идут, некоторый
стержень имен с людьми, и так YP живет на префиксе к именам больш команд
типа ypserv, ypbind, и т.д. Сегодня, NIS доступны для виртуально всего
Un*ces и там даже свободно реализуется. Каждый - из BSD разъединения
Сеть -2 выпуск, и был получен из общей пожертвованной реализации сноски
области Sun. Библиотечная клиентская цифра из этого разъединения была в GNU
Libc в течение длительного времени, в то время как административные
программы только недавно пренесенные к Linux Swen Thmmler. (1) NIS
сервер - отсутствуетиз реализации сноски. Tobias Reber написал другой
NIS пакет, е средства и сервер; это называется yps. (2)
В настоящее время(постоянно), полная перезапись цифры NIS, называемой
NYS, сделанная Peter Eriksson, (3), который поддерживает оба, и plain
NIS и Sun's much пересмотренным NIS.
1. swen@uni-paderborn.de. NIS клиентура доступнаы как yp-
linux.tar.gz из sunsite.unc.edu в СИСТЕМА / СЕТЬ. 2. Текущая верчия *от
этой записи) - yps-0.21 и может быть получена из ftp.lysator.liu.se в
/pub/NYS каталоге. 3. pen@lysator.liu.se.
+. NYS не только обеспечивает множество NIS инструментальных
средств и сервера, но и также прибавляет новое множество
библиотечных функций, которые будут наиболее возможными для того, чтобы
попасть в стандарт libc в конечном счете. Это включает новую
конфигурационную схему порции hostname решения, которое заменяет
текущую схему использованную host.conf. Особенности этих функций
будут обсуждены ниже.
Эта глава сосредоточится на NYS скорее чем на двух других
пакетах, к которому я буду относить как " традиционную " NIS цифру. Если
Вы хотите запустить этих пакетов, то команд, описанных в этой главе
может быть не достаточно. Чтобы получать дополнительн ую информацию,
пожалуйста найдите стандартную книгу по NIS, типа NFS Hal Stern's и NIS
(см. [GETST "строгий - nfs"]).
В настоящее время, NYS - все еще развивается, и следовательно
стандартные Linux утилиты типа сетевых программ или входа в систему
программ, еще не знает NYS схему конфигурации. Пока NYS соединяется в
mainstream libc Вы должны перетранслировать все эти binaries, если Вы
хотите заставить их использовать NYS. В любом из этих приложений
формирования файла, точно определите -lnsl как последнюю опция libc к
компоновщику. Это связывается на релевантных функциях из libnsl, NYS
стандарной библиотекы для C.
11.1 Знакомство с NIS
NIS хранит информацию баз данных, находящихся в так
называемых отображениях, содержащих keyvalue pairs. Отображения
сохранены на центральном хосте, выполняющем NIS сервер, из которого
клиентура может отыскивать информацию через различные RPC вызовы.
Совершенно часто, отображения сохранены в файлах DBM. (4)
Отпбражения сами по себе обычно генерируются из текстовых файлов
типа /etc/hosts или /etc/passwd. Для некоторых файлов, отдельные
отображения - созданы, один для каждого типа клавиши. Например, Вы
можете искать хост файл для имени хоста также как для адреса IP.
Соответственно, два NIS отображения получены из файла, вызываемый
hosts.byname и hosts.byaddr, соответственно. Таблица 11.1 списков общих
отображений и файлов из кооторых они сгенерированны.
4. DBM - простая библиотека управления базой данных которая
использует метод хеширования, чтобы ускорить операцию исследования. Имеется
свободная DBM реализация из GNU проектируемая вызываемой Gdbm, который
является частью большинства Linux распространен ия.
-----------------------------------------------------------
+-----------------+---------------------------------------+
|Master File | Map(s) |
+-----------------+---------------------------------------+
+-----------------+---------------------------------------+
|/etc/hosts | hosts.byname hosts.byaddr |
|/etc/networks | networks.byname networks.byaddr |
|/etc/passwd | passwd.byname passwd.byuid |
|/etc/group | group.byname group.bygid |
|/etc/services | services.byname services.bynumber |
|/etc/rpc | rpc.byname rpc.bynumber |
|/etc/protocols | protocols.byname protocols.bynumber |
|/usr/lib/aliases | mail.aliases |
+-----------------+---------------------------------------+
+-----------------+---------------------------------------+
Таблица 1. Некоторый стандарт NIS отображения и соответствующие
чайлы.
Имеются другие файлы и отображения, которые Вы можете найти в
любом NIS пакете или другом. Они могут содержать информацию для
приложений не обсуждаемых в этой книге, типа bootparams отображения,
которое может использоваться некоторыми BOOTP серверами, или подобно
которому в настоящее время не имеют любую функцию в Linux
(Ethers.byname и ethers.byaddr отображения).
Для некоторых отображений, люди обычно используют прозвища,
которые являются короткими следовательно проще. Получать полный список
прозвищ понимаемый вашими NIS инструментальными средствами, запустите
следующую команду:
$ ypcat -x
NIS map nickname translation table:
"passwd" -> "passwd.byname"
"group" -> "group.byname"
"networks" -> "networks.byaddr"
"hosts" -> "hosts.byname"
"protocols" -> "protocols.bynumber"
"services" -> "services.byname"
"aliases" -> "mail.aliases"
"ethers" -> "ethers.byname"
"rpc" -> "rpc.bynumber"
"netmasks" -> "netmasks.byaddr"
"publickey" -> "publickey.byname"
"netid" -> "netid.byname"
"passwd.adjunct" -> "passwd.adjunct.byname"
"group.adjunct" -> "group.adjunct.byname"
"timezone" -> "timezone.byname"
NIS сервер традиционно называется ypserv. Для средней сети
единственного сервера обычно хватает; большие сети могут выбирать несколько
серверов на различных машинах и различных сегментах сети, чтобы уменьшить
загрузку на машинах сервера и программах маршрутизации. Они
синхронизированы, делая один из них главным сервером, к другие
подчиненными серверами. Отображения будут созданы только на master
server's host. Оттуда, они распределены всем slaves/
Вы отметили, что мы говорили относительно " сети " очень
неопределенно все время; конечно имеется отличительное понятие в NIS,
которое относится к такой сети, и которая является системой всех хостов
та часть их данных конфигурации системы сделанны через NIS: NIS
область. К сожалению, NIS области не имеют абсолютно ничего общего с
областями, с которыми мы столкнулись в DNS. Избегая любой
неоднозначности через эту главу, я буду всегда точно определять который
тип области
NIS области имеют совершенно административную функцию только. Они
обычно невидимы для пользователей, кроме разделения паролей между всеми
машинами в области. Следовательно, название, данное NIS области
релевантно только администраторам. Обычно, любое название будет как
длинный поскольку это отлично от любого другого NIS названия области на
вашей локальной сети. апример, администратор в Virtual Brewery может
создайть две NIS области, одну для Brewery непосредственно, и о
которыу она называет brewery и winery, соответственно. Другая
совершенно общая схема для того, чтобы просто использовать DNS
название области для NIS. Чтобы установить и показать NIS название
области вашего множества, domainname. Когда она вызывается без любого
аргумента, это печатает текущее NIS название области; к множеству названия
области, Вы должны стать супер пользователеми ввести:
# domainname brewery
NIS области определяют, какой NIS сервер-приложение сделает
запрос. Например, программа входа в систему на множестве в Winery должна,
сделать запрос NIS сервера Winery (или один из них, если они там были
отделены) для информации пароля пользователя; в то время как приложение на
Brewery host должно приклеится к серверу Brewery'.
Одна тайна, которая пстазтся все еще не решенной, а именно, как
клиент узнает с каким сервером он соединен. Самое простое приближение
было бы иметь файл конфигурации, который называет хост, чтобы найти
сервер. Однако, это приближение было бы довольно негибко, потому что
это не позволяет клиентуре использовать различные серверы (из той
же самой области, конечно), в зависимости от их доступности.
Следовательно, традиционный NIS implementations полагаются на специальный
d чтобы обнаружить подходящий NIS сервер в их NIS области. Перед
способностью выполнить любой NIS
Запрос, любое приложение, сначала выясняти от ypbind который
сервер используется.
Ypbind исследует серверы, передавая к локальной IP сети; сначало
первый ответ принят, чтобы быть потенциально самым быстрым и будет
использоваться во всех последовательных запросах NIS. После того, как
некоторый интервал истек, или если сервер становится недоступным, ypbind,
исследует активные серверы снова.
Теперь, спорная точка относительно динамического связывания - то,
что Вы редко нуждайтесь в этом, и что это вводит задачу защиты:
ypbind слепо верит, кто бы ни отвечаел, который мог бы быть NIS сервером
также как и "злоумышленник". Само собой разумеется это становится
затруднением - если Вы управляете вашими базами данных паролей над NIS.
Для принятия мер против этого, NYS не использует ypbind по умолчанию, но
подбирает сервер для имени хостаиз файла конфигурации.
11.2 NIS против NIS +
NIS и NIS + принимают участие немногим больше чем их название и общая
цель. NIS + структуирован полностью различным способом. Вместо плоского
названия пространство с разделенными NIS областями, это использует
иерархическое название, оставляют промежутки подобные к таковому DNS.
Вместо отображений, так называемых таблиц используются то, что составлено
из строк и столбцов, где лаждая строка представляет предмет в NIS + базе
данных, в то время как столбцы покрывают те реквизит + знает и заботится
относительно них. Каждая таблица для данный NIS + - область
включающяя таковых родительских областей. Кроме того, запись в таблице
может содержать связь с другой таблице. Эти особенности делают его
возможным к получении информации многими способами.
Традиционный NIS имеет RPC номер версии 2, в то время как NIS + -
версию - 3.
NIS + не кажется, очень широко используемым однако, и я
действительно не знаю многого относительно этого. (Хорошо, почти ничего).
По этой причине, мы не будет связываться с этим здесь. Если Вы
заинтересованы в изучении большего, пожалуйста обратитесь к NIS Sun +
справочника администратора ([GETST "nisplus"]).
11.3 Клиентская Сторона NIS
Если Вы знакомы с записью или перенесением приложений сети, Вы
обязательно заметите, что большинство NIS отображений, перечисленных выше
соответствуют библиотеке функций в библиотеке C. Например, чтобы
получить passwd информацию, Вы используете getpwnam (3) и getpwuid
функции (3) которая возвращает информацию счета, связанная с данным
именем пользователя или численной идентичностью пользователя. При
нормальных обстоятельствах, эти функции будут выполнены при запросе
по на стандартном файле, типа /etc/passwd.
Nis-знающяя реализация этих функций, однако, будет модифицированна, и
место обращения RPC для того, чтобы иметь NIS сервер для поиска имен
пользователя или идентичность. Это случается полностью с приложением.
Функция может также "конкатенировать " NIS отображение или " заменить "
первоначальную картотеку с этим. Конечно, это не относится к реальной
модификации файла, это только означает то, что он появляется к приложению
как если бы файл был бы заменен или конкатенирован.
Для ттадиционных NIS реализаций, там использовались общие
условия, относительно которых замененные отображения, и которые были
конкатенированы к исходной информации. Некоторые, подобно passwd
отображениям, требуемым kludgy modifications картотеки passwd, который,
когда выполнен неправильно, обнаружил бы защиту. Чтобы избежать этого
pitfalls, NYS использует общую схему конфигурации это определяет,
использует ли частное множество клиентских функций первоначальную
карто и в каком порядке. Это будет описанный позже.
Назад | Содержание | Вперед
Виртуальные VPS серверы в РФ и ЕС
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
