В некоторых приложениях применяются собственные механизмы безопасности. Убедитесь, что эти механизмы настроены надлежащим образом. В частности, проверьте r-команды Unix, а именно набор сетевых Unix-приложений, сравнимых с ftp и telnet.
Необходимо знать точно, что r-команды ненанесут вреда безопасности системы. Неверно настроенные r-команды могут открыть доступ к вашим компьютерам практически всем желающим. Вследствие этого r-команды использовать не рекомендуется.
Вместо парольной аутентификации r-команды действуют по системе доверенных узлов и пользователей. Доверенным пользователям с доверенных узлов разрешается доступ к локальной системе без пароля. Доверенные узлы называют также «равноценными узлами», поскольку система предполагает, что пользователь, имеющий доступ к доверенному узлу, должен иметь рав ноценный доступ к локальному узлу. Предполагается, что учетные записи с одинаковыми именами на разных узлах «принадлежат» одному пользовате лю. Например, пользователь becky на доверенном узле имеет те же полномочия доступа, что и пользователь becky локальной системы.
Такой механизм проверки подлинности требует присутствия баз данных, определяющих доверенные узлы и доверенных пользователей. Такими база ми данных для r-команд служат файлы /etc/hosts.equiv и .rhosts.
Файл /etc/hosts.equiv определяет, какие узлы и пользователи могут иметь доступ к локальной системе посредством r-команд. Файл может также явным образом запрещать доступ определенным узлам и пользователям. Отсутствие доверительного доступа не значит, что доступ пользователю запрещен; пользователь по-прежнему может получить доступ, указав пароль. Базовый формат записей файла /etc/hosts.equiv:
[+ | -][имя узла] [+ | -][имя пользователя]
Здесь имя узла - это имя «доверенного» узла, которому может предшествовать знак сложения (+). Знак сложения не имеет особого смысла, за исключением случая, когда фигурирует отдельно, без имени узла. Знак сложения без имени узла - это маска, обозначающая все узлы.
Пользователям равноценного узла разрешено работать с вашей системой, не указывая пароля, при условии, что совпадают имена учетных записей. (Это одна из причин для администраторов соблюдать последовательность в выборе регистрационных имен.) Необязательное имя пользователя - это имя пользователя доверенного узла, которому предоставляется доступ ко всем учетным записям. Указание имени пользователя означает, что пользователь не ограничен учетной записью с идентичным именем, но получает беспарольный доступ ко всем пользовательским учетным записям.
Имени узла может предшествовать знак вычитания (-), который говорит о том, что указанный узел не является равноценной системой. Пользователи этого узла, обращаясь к локальной системе при помощи r-команд, всегда должны указывать пароль. Знак вычитания может предшествовать также имени пользователя. В таком случае, независимо от других разрешенных для узла действий, указанный пользователь не является доверенным, и всегда обязан указывать пароль.
Следующие примеры иллюстрируют интерпретацию записей файла hosts.equiv:
rodent Разрешает беспарольный доступ к локальной системе всем пользовате- лям узла rodent, для которых существуют учетные записи с идентичны- ми именами.
-rodent Запрещает беспарольный доступ всем пользователям узла rodent,
rodent -david Запрещает беспарольный доступ пользователю david узла rodent,
rodent +becky Разрешает пользователю becky узла rodent беспарольный доступ ко всем учетным записям (кроме root) локальной системы.
+ becky Разрешает пользователю becky беспарольный доступ ко всем учетным записям (кроме root) локальной системы независимо от того, с какой системы работает пользователь.
Последняя запись - пример того, чего никогда не следует допускать при настройке. Не используйте просто знак сложения вместо имени узла. Он разрешает доступ с любых узлов и открывает широкие просторы для деятельности злоумышленников. Например, если приведенная выше запись присутствует в файле hosts.equiv, злоумышленник может создать на своей системе учетную запись becky и получить доступ ко всем учетным записям вашей системы. Проверьте файлы /etc/hosts.equiv, -/.rhosts и /etc/liosts.lpd на предмет наличия опасных +-записей. Не забудьте проверить файлы .rhosts во всех домашних каталогах пользователей.
Простая опечатка может стать причиной появления самостоятельного знака сложения. К примеру, возьмем такую запись:
+ rodent becky
Системный администратор, вероятно, имел в виду «предоставить becky беспарольный доступ ко всем учетным записям, если обращение исходит от узла rodent». Однако лишний пробел после символа + изменяет смысл записи на такой: «разрешить пользователям rodent и becky беспарольный доступ, если обращение исходит от любого узла». Не используйте символ + перед именем узла и всегда проявляйте осторожность в работе с файлом /etc/ hosts.equiv, чтобы избежать неприятных последствий.
Работая с файлом /etc/hosts.equiv, предоставляйте доверенный доступ лишь системам и пользователям, которым действительно доверяете. Ни в коем случае не следует доверять всем системам локальной сети. Более того, лучше вообще не пользоваться r-командами. Если же без них не обойтись, доверяйте только узлам локальной сети, для которых известны ответственные лица, которые доступны лишь ограниченному кругу пользователей, и только в случае, если локальная сеть защищена брандмауэром. Не стоит предоставлять доступ по умолчанию - должны быть причины для присвоения статуса доверенного пользователя или узла. Никогда не доверяйте внешним системам.
Злоумышленник может с легкостью нарушить маршрутизацию или скорректировать данные DNS, чтобы обмануть вашу систему и получить доступ. Кроме того, никогда не начинайте файл hosts.equiv со знака вычитания. В некоторых системах это приводит к некорректному предоставлению доступа. Создавая файл hosts.equiv, всегда лучше перестраховаться. Добавлять доверенные узлы по мере их появления гораздо легче, чем восстанавливать систему после атаки злоумышленника.
Файл .rhosts разрешает или блокирует беспарольный доступ посредством r-команд для учетной записи конкретного пользователя. Он хранится в исходных каталогах пользователей и содержит записи для доверенных узлов и пользователей. Формат записей файла .rhosts совпадает с форматом записей hosts.equiv, и записи действуют почти таким же образом. Различие заключено в границах доступа, который предоставляют записи. Записи файла .rhosts предоставляют или запрещают доступ к учетной записи отдельного пользователя, записи файла hosts.equiv управляют доступом к системе в целом.
Данное функциональное различие можно проиллюстрировать на простом примере. Рассмотрим такую запись:
horseshoe anthony
В файле hosts.equiv узла crab данная запись разрешает пользователю antho пу узла horseshoe беспарольный доступ к любой учетной записи crab. В файле .rhosts в исходном каталоге пользователя resnick точно такая же запись разрешает пользователю anthony обратиться посредством rlogin с узла horseshoe к учетной записи resnick, не предоставляя пароля, но не предоставляет беспарольного доступа к прочим учетным записям узла crab.
Пользователь при помощи файла .rhosts может определить в качестве равноценных принадлежащие ему различные учетные записи. Приведенный выше пример записи может иметь место, вероятнее всего, лишь в том случае, если пользователи anthony и resnick - одно лицо. Например, у меня есть учетные записи в ряде различных систем. Иногда мое имя пользователя - hunt, а иногда - craig.
Было бы здорово иметь везде одинаковые имена учетных записей, но это не всегда возможно; в моей локальной сети имена craig и hunt уже используются другими людьми. Я хочу иметь возможность обратиться к своей рабочей станции с любого узла, на котором у меня есть учетная запись, но запретить доступ другим пользователям с именами craig и hunt. Файл .rhosts позволяет мне решить эту задачу.
Допустим, мое имя на узле crab - craig, а на узле filbert - hunt. Имя другого пользователя узла filbert - craig. Чтобы получить беспарольный доступ к своей учетной записи на crab с узла filbert, а также запретить такой доступ второму пользователю, я создаю следующий файл .rhosts в своем исходном каталоге:
filbert hunt filbert -craig
Как правило, прежде всего происходит обращение к файлу hosts.equiv, а затем - к файлу пользователя .rhosts, если таковой существует. Первое явное соответствие определяет, разрешен ли беспарольный доступ. Следовательно, файл .rhosts имеет приоритет меньший, нежели файл hosts.equiv. Исключением из этого правила является доступ для пользователя root. Когда администратор системы пытается получить доступ к системе при помощи r-команд, происходит чтение только файла .rhosts в исходном каталоге пользователя root. Это позволяет более жестко управлять доступом пользователя root. Если бы для разграничения root-доступа использовались файлы hosts.equiv, записи, предоставляющие доступ доверенным узлам, давали бы пользователям root этих узлов полномочия администратора на локальной системе. Можно добавлять доверенные узлы в hosts.equiv, не предоставляя удаленным администраторам root-доступ к локальной системе.
Следует помнить, что пользователь способен предоставить доступ посредством файла .rhosts, даже если файл hosts.equiv не существует. Единственный способ воспрепятствовать этому - периодически проверять наличие файлов .rhosts и удалять их. До тех пор пока в системе присутствуют r-команды, пользователи имеют возможность случайно нарушить безопасность системы.