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. „л