17 и 19, обычно используемый для старт-сигнала(XON) и стоп-сигнала(XOFF)) должно быть escaped, то Вам надо использовать следующую опцию: Asyncmap 0x000A0000 Максимум получает единицу, или MRU, сообщает peer максимальный размер HDLC рамки, которую мы хотим получить. Хотя это может напомнить Вам значение MTU (Максимальная Порция обмена), то эти два имеет немного общего. MTU - параметр kernel устройства работы с сетями, и описывает максимальную структуру inerface делая его способным к обработке. MRU более, чем совета к remote end для того, чтобы не генерировать любой фрейм больший чем MRU; interface должен однако быть способен 1500 байт. Выбор MRU не такой большой вопрос того что как связь способна к пересылке, но того, что даст Вам самый лучший throughput. Если Вы имеете в виду интерактивные приложения над связью, то установки MRU к значениям всего 296 - хорошая идея, так, чтобы случайный больший блок (говорят, из FTP сеанса) не сделал бы ваш курсор "jump''. Чтобы сообщить - 155 - pppd чтобы он запросил MRU 296, Вы бы дали ему опцию mru 296. Малый MRUs, однако, только имеет смысл, если Вы не имеете эту опцию (это отключается по умолчанию). Pppd понимает также пару LCP опций, которые конфигурируют полное поведение процесса переговоров, типа максимального номера из запросов конфигурации, которые могут быть обменены перед тем как связь будет прервана. & " В заключение, имеются две опции, которые обращаются к LCP ECHO сообщениям. PPP определяет эти два сообщения, запрос ECHO и ответ ECHO. Pppd использует эту особенность, чтобы проверить, действует ли связь все еще. Вы можете отключить это используя опцию lcp-echo-interval вместе со временем мгновенно. Если никакие структуры не получены от отдаленного хоста внутри этого интервала, то pppd сгенерирует запрос ECHO, и будет ожидает, какой ECHO ответ peer возвратит. Если peer не возвращает ответ, то связь будет прервана после некоторого числа посланных запросов. Этот номер может быть установлен используя опцию lcp-echo-failure. По умолчанию, эта особенность отключена в целом. 9.9 Общие рассмотрения защиты Плохо сконфигурированный PPP daemon может быть разрушителен для защиты. Это может быть так плохо, как разрешение подсоединиться любому человеку со своего компьютера в Вашу Ethernet (и это очень плохо). В этом разделе, мы обсудим несколько критериев, которые должны сделать вашу PPP конфигурацию безопасной. Одна проблема с pppd - то, что конфигурация сетевого устройства и таблицы маршрутов требуют привилегии root. Вы будете обычно разрешать эту сложность, выполняя setuid root. Однако, pppd позволяет пользователям установить различные защита-релевантные опции. Для защиты против любого нападения, пользователь может манипулировать этими опциями, Вам предложат установить пару значений по умолчанию в глобальном файле /etc/ppp/options, подобно тем показанным в типов 9.4. Некоторые из них, типа опознавательных опций, не могут быть - 156 - отменены пользователем, и так что они обеспечивают приемлемую защиту против манипулирований. Конечно, Вы должны защитить себя от систем, с которыми PPP также общается. Чтобы отразить хосты, Вы должны всегда иметь некоторый вид установления подлинности от вашего peer. Дополнительно, Вы не должпы позволять иностранным хостам использовать любой адрес IP какой они выберут, но ограничьте их по крайней мере несколькими. Следующий раздел будет связам с этими проблемами. 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 клиента. Сервер теперь выполняет то же самое вычисление, и подтверждает клиента. - 157 - Другая особенность 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 шифров. Таким образом, Вы можете удостовериться в том, что никакая неопознанная система не соединяется с Вашим хостом. - 158 - Следующие два раздела обсуждают два 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) и находит - 159 - первую линию, показанную выше. Затем производится 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: он ищет в файле шифров. - 160 - Как было объяснено прежде, отдаленный 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ро. - 161 - Вторая линия описывает, как пользователь именнованняй 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, и - 162 - дадите этому 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, или в глобальном файле опций. Руководство также обсуждает более специфические опции для вкл. или выкл. индивидуальных опознавательных протоколов. - 163 - 10. Различные сетевые приложения После успешной установки IP и решающего устройства, Вы должны обратиться к услугам обеспечивающим хорошую работу над сетью. Глава начинается с конфигурачия пескольких простых сетевых приложений, включая Inetd сервер, и программы из rlogin совокупности. Незначительная процедура обращения связывает, с помощью интерфейса, эти услуги подобно Сетевой Файловой системе (NFS). Сетевая Информационная Система (NIS) основана на том же самом, имела дело с briefly. Конфигурация NFS и NIS, однако берущяя большое количество памяти, будет описана в отдельных главах. Это применяется к электронной почте и netnews также. Конечно, мы не можем описать все сетевые приложения в этой книге. Если Вы хотите устанавить то, которое не обсуждается здесь, подобно переговорам, gopher, или xmosaic пожалуйста обратитесь к руководству для деталей. 10.1 Inetd супер-сервер Часто, услуги предоставляются так называемыми daemons. Daemon является программой, которая открывает некоторый порт, и связь. Если это происходит, это создает дочерний процесс, который принимает связь, в то время как основной продолжает ждать дальнейших запросов. Это понятие имеет недостаток что для каждого предлагаемого обслуживания, daemon должен запускать те, которые слушают порте для связи, для которых это вообще означает потери способов системы подобно пространст Таким образом, почти вся Un*x инсталляция запускает " супер- сервер ", который создает гнезда для ряда услуг, и слушает на них одновременно при использовании отобранного системного вызова (2). Когда отдаленный хост запрашивает одну из услуг, супер-сервер замечает этот и порождает другой сервер, точно установленный для этого порта. Супер-сервер, обычно используемый - inetd, Internet Daemon. Это начинается при начальной загрузке системы, и берет список услуг, к - 164 - которым он обращается из файла запуска, именованной /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. Противоположный тип, "многопоточные " серверы, позволяет безграничному числу образцов, чтобы быть запущенными одновременно; но это редко когда - 165 - используется. Эти серверы должны точно определить 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 для этой проблемы, удостоверитесь, что ограниченная - 166 - область действия к директориям клиентов будет восстановлена из файлов, добавляя те названия каталогов к команде 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 - 167 - 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 (в этом порядке) для соответствующей записи и сервисного и клиентского хоста. Если запись соответствия была найдена в - 168 - тся, независимо от любой записи в 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; \ - 169 - 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 - 170 - 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 запрос к серверу, наряду с параметрами процедуры. Сервер вызовет обозначенную процедуру по защите клиента, вручая обратно возвращаемое значение, если имеется любое. Чтобы быть машинно-независимыми, зсе жанные, обмененные между клиентом и сервером - 171 - преобразованны к так называемому Внешнему Представлению Данных (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 серверов, выполняющиеся на машине: клиент, который хочет войти в контакт с обслуживанием с данным номером программы сначала сделает запрос - 172 - 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 - 173 - Рис. 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 как к Локальному пользователю. - 174 - Теперь, когда типы 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. - 175 - " / 165 - Форматфайла.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 к этому концу должен хранить насущными данные типа пользователя синхронизированные между всеми - 176 - множествами. Мы видели перед этим, что для решенияимени хоста, мощное и сложное обслуживание существует, являющееся DNS. Дл