Страница:
и будет ожидает, какой 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 -
возвращает ответ, то связь будет прервана после некоторого числа
посланных запросов. Этот номер может быть установлен используя опцию
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 -