Хант Крэйг. TCP/IP Сетевое администрирование

Подождите немного. Документ загружается.

452 Глава 12. Сетевая безопасность

нанесут вреда безопасности системы. Неверно настроенные г-команды могут

открыть доступ к вашим компьютерам практически всем желающим.

Вследствие этого г-команды использовать не рекомендуется.

Вместо парольной аутентификации r-команды действуют по системе дове-

ренных узлов и пользователей. Доверенным пользователям с доверенных уз-

лов разрешается доступ к локальной системе без пароля. Доверенные узлы

называют также «равноценными узлами», поскольку система предполагает,

что пользователь, имеющий доступ к доверенному узлу, должен иметь рав

ноценный доступ к локальному узлу. Предполагается, что учетные записи с

одинаковыми именами на разных узлах «принадлежат» одному пользовате

лю. Например, пользователь becky на доверенном узле имеет те же полномо-

чия доступа, что и пользователь becky локальной системы.

Такой механизм проверки подлинности требует присутствия баз данных,

определяющих доверенные узлы и доверенных пользователей. Такими база

ми данных для г-команд служат файлы /etc/hosts.equiv и .rhosts.

Файл /etc/hosts.equiv определяет, какие узлы и пользователи могут иметь

доступ к локальной системе посредством г-команд. Файл может также яв-

ным образом запрещать доступ определенным узлам и пользователям. От-

сутствие доверительного доступа не значит, что доступ пользователю запре-

щен; пользователь по-прежнему может получить доступ, указав пароль.

Базовый формат записей файла /etc/hosts.equiv:

[+ | -][имя узла] [+ | -][имя

пользователя]

Здесь имя узла - это имя «доверенного» узла, которому может предшество-

вать знак сложения (+). Знак сложения не имеет особого смысла, за исклю-

чением случая, когда фигурирует отдельно, без имени узла. Знак сложения

без имени узла - это маска, обозначающая все узлы.

Пользователям равноценного узла разрешено работать с вашей системой, не

указывая пароля, при условии, что совпадают имена учетных записей. (Это

одна из причин для администраторов соблюдать последовательность в выбо-

ре регистрационных имен.) Необязательное имя пользователя - это имя поль-

зователя доверенного узла, которому предоставляется доступ ко всем учет-

ным записям. Указание имени пользователя означает, что пользователь не

ограничен учетной записью с идентичным именем, но получает беспароль-

ный доступ ко всем пользовательским учетным записям.

Имени узла может предшествовать знак вычитания (-), который говорит о

том, что указанный узел не является равноценной системой. Пользователи

этого узла, обращаясь к локальной системе при помощи г-команд, всегда

должны указывать пароль. Знак вычитания может предшествовать также

имени пользователя. В таком случае, независимо от других разрешенных

для узла действий, указанный пользователь не является доверенным, и

всегда обязан указывать пароль.

За исключением учетной записи root.

Проверка подлинности пользователей 453

Следующие примеры иллюстрируют интерпретацию записей файла hosts.eq-

uiv:

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, предоставляйте доверенный доступ лишь

системам и пользователям, которым действительно доверяете. Ни в коем

случае не следует доверять всем системам локальной сети. Более того, луч-

ше вообще не пользоваться г-командами. Если же без них не обойтись, дове-

ряйте только узлам локальной сети, для которых известны ответственные

454 Глава 12. Сетевая безопасность

лица, которые доступны лишь ограниченному кругу пользователей, и толь-

ко в случае, если локальная сеть защищена брандмауэром. Не стоит предо-

ставлять доступ по умолчанию - должны быть причины для присвоения ста-

туса доверенного пользователя или узла. Никогда не доверяйте внешним

системам. Злоумышленник может с легкостью нарушить маршрутизацию

или скорректировать данные DNS, чтобы обмануть вашу систему и получить

доступ. Кроме того, никогда не начинайте файл hosts.equiv со знака вычита-

ния. В некоторых системах это приводит к некорректному предоставлению

доступа. Создавая файл hosts.equiv, всегда лучше перестраховаться. Добав-

лять доверенные узлы по мере их появления гораздо легче, чем восстанавли-

вать систему после атаки злоумышленника.

Файл .rhosts разрешает или блокирует беспарольный доступ посредством

г-команд для учетной записи конкретного пользователя. Он хранится в ис-

ходных каталогах пользователей и содержит записи для доверенных узлов и

пользователей. Формат записей файла .rhosts совпадает с форматом записей

hosts.equiv, и записи действуют почти таким же образом. Различие заключе-

но в границах доступа, который предоставляют записи. Записи файла .rhosts

предоставляют или запрещают доступ к учетной записи отдельного пользо-

вателя, записи файла hosts.equiv управляют доступом к системе в целом.

Данное функциональное различие можно проиллюстрировать на простом

примере. Рассмотрим такую запись:

horseshoe anthony

В файле hosts.equiv узла crab данная запись разрешает пользователю antho

пу узла horseshoe беспарольный доступ к любой учетной записи crab. В фай-

ле .rhosts в исходном каталоге пользователя resnick точно такая же запись

разрешает пользователю anthony обратиться посредством rlogin с узла hor-

seshoe к учетной записи resnick, не предоставляя пароля, но не предоставля-

ет беспарольного доступа к прочим учетным записям узла crab.

Пользователь при помощи файла .rhosts может определить в качестве равно-

ценных принадлежащие ему различные учетные записи. Приведенный вы-

ше пример записи может иметь место, вероятнее всего, лишь в том случае,

если пользователи anthony и resnick - одно лицо. Например, у меня есть

учетные записи в ряде различных систем. Иногда мое имя пользователя -

hunt, а иногда - craig. Было бы здорово иметь везде одинаковые имена учет-

ных записей, но это не всегда возможно; в моей локальной сети имена craig и

hunt уже используются другими людьми. Я хочу иметь возможность обра-

титься к своей рабочей станции с любого узла, на котором у меня есть учет-

ная запись, но запретить доступ другим пользователям с именами craig и

hunt. Файл .rhosts позволяет мне решить эту задачу.

Допустим, мое имя на узле crab - craig, а на узле filbert - hunt. Имя другого

пользователя узла filbert - craig. Чтобы получить беспарольный доступ к

своей учетной записи на crab с узла filbert, а также запретить такой доступ

второму пользователю, я создаю следующий файл .rhosts в своем исходном

каталоге:

Проверка подлинности пользователей 455

filbert hunt

filbert -craig

Как правило, прежде всего происходит обращение к файлу hosts.equiv, а за-

тем - к файлу пользователя .rhosts, если таковой существует. Первое явное

соответствие определяет, разрешен ли беспарольный доступ. Следовательно,

файл .rhosts имеет приоритет меньший, нежели файл hosts.equiv. Исключе-

нием из этого правила является доступ для пользователя root. Когда адми-

нистратор системы пытается получить доступ к системе при помощи г-ко-

манд, происходит чтение только файла .rhosts в исходном каталоге пользо-

вателя root. Это позволяет более жестко управлять доступом пользователя

root. Если бы для разграничения root-доступа использовались файлы

hosts.equiv, записи, предоставляющие доступ доверенным узлам, давали бы

пользователям root этих узлов полномочия администратора на локальной

системе. Можно добавлять доверенные узлы в hosts.equiv, не предоставляя

удаленным администраторам root-доступ к локальной системе.

Следует помнить, что пользователь способен предоставить доступ посредст-

вом файла .rhosts, даже если файл hosts.equiv не существует. Единственный

способ воспрепятствовать этому - периодически проверять наличие файлов

.rhosts и удалять их. До тех пор пока в системе присутствуют г-команды,

пользователи имеют возможность случайно нарушить безопасность системы.

Защищенный интерпретатор команд

Слабая защищенность г-команд представляет угрозу безопасности системы.

Этими командами нельзя пользоваться для обеспечения защищенного уда-

ленного доступа, даже учитывая все аспекты, описанные в предшествую-

щем разделе. В лучшем случае доступ посредством г-команд можно предо-

ставлять только доверенным системам защищенной локальной сети. Причи-

на кроется в том, что доверие г-команд основывается на убежденности в чет-

ком соответствии IP-адреса совершенно определенному компьютеру.

Обычно так и есть. Однако злоумышленник способен исказить данные DNS

и подменить адрес IP либо данные маршрутизации с целью доставки инфор-

мации в другую сеть, таким образом обойдя механизмы проверки подлин-

ности, используемые в г-командах.

Альтернативой такому удаленному доступу является защищенный интер-

претатор команд. Защищенный интерпретатор заменяет стандартные г-ко-

манды более защищенными вариантами, задействующими шифрование и

более совершенный механизм проверки подлинности. Последний позволяет

гарантировать, что доверенный узел действительно является таковым. Ме-

тоды шифрования на основе открытых ключей реализуют проверку подлин-

ности пакетов сетевого потока. Защищенный интерпретатор команд не толь-

ко безопасен, но и легок в применении.

В настоящее время широкое распространение получили два варианта защи-

щенного интерпретатора команд: коммерческий продукт SSH Secure Shell и

продукт с открытым исходным кодом - OpenSSH. OpenSSH входит в состав

456

Глава 12. Сетевая безопасность

различных вариантов Unix и Linux, а оба продукта - как коммерческий, так

и бесплатный - доступны для загрузки из сети Интернет на случай, бели »

вашей системе нет никакого. Примеры этого раздела созданы с применени

ем OpenSSH, но базовые функции обоих вариантов интерпретатора по су-

ществу одинаковы.

Основные компоненты защищенного интерпретатора команд:

sshd

Демон защищенного интерпретатора команд обрабатывает входящие

SSH-соединения. sshd следует запускать в процессе загрузки системы - ю

загрузочного сценария, но не при помощи inetd.conf. При каждом запус-

ке sshd генерирует ключ шифрования, поэтому его запуск может быть

слишком долгим для inetd.conf. На системе, принимающей SSH-соедине-

ния, должен работать демон sshd.

ssh

Пользовательская команда для защищенного интерпретатора команд. Ко

манда ssh заменяет rsh и rlogin. Она позволяет передать команду удален

ной системе либо провести сеанс работы с удаленной системой безопас

ным способом. Команда создает исходящие соединения, обращенные к

удаленному демону защищенного интерпретатора команд. Система-кли

ент для работы с SSH-соединением должна иметь доступ к команде ssh.

scp

Команда scp (secure сору) является заменой команды rep.

ssh-keygen

Генерирует открытый и закрытый ключи шифрования, используемые

для защищенной передачи данных.

sftp

Вариант клиента FTP, работающий через защищенное соединение.

Когда ssh-клиент обращается к серверу sshd, они обмениваются открытыми

ключами. Системы сравнивают полученные ключи с ключами, хранимыми

в файлах /etc/ssh_known_hosts и .ssh/known_hosts (в исходном каталоге

пользователя).

Если ключ не найден или изменился, пользователю предла-

гается подтвердить прием ключа:

> ssh horseshoe

Host key not found from the list of known hosts.

Are you sure you want to continue connecting (yes/по)? yes

Host 'horseshoe' added to the list of known hosts.

craig's password: Watts.Watt.

Last login: Thu Sep 25 15:01:32 1997 from rodent

Администратор системы может инициализировать файл ssh_known_hosts, выпол-

нив команду make-ssh-known-hosts, которая извлекает ключи всех узлов выбранно-

го домена.

Проверка подлинности пользователей

457

Linux 2.0.0.

/usr/X11/bin/xauth: creating new authority file /home/craig/.Xauthority

Если ключ обнаружен в одном из файлов либо принят пользователем, кли-

ент использует его для шифрования случайным образом сгенерированного

ключа сеанса. Ключ сеанса передается серверу, и обе системы используют

итот ключ для шифрования данных до конца текущего сеанса SSH.

Клиент проходит проверку подлинности, если он упомянут в файле hosts.eq-

uiv, shost.equiv, пользовательском файле .rhosts либо файле .shosts. Такой

механизм проверки подлинности схож с тем, что используется г-командами,

а формат файлов shost.equiv и .shosts совпадает с форматом их г-эквивален-

тов. Обратите внимание, что в приведенном выше примере пользователю бы-

ло предложено набрать пароль. Если клиент не упомянут в одном из файлов,

включается механизм парольной аутентификации. Как можно видеть, па-

роль отображается открытым текстом. Однако не стоит беспокоиться о краже

пароля, поскольку SSH шифрует его, прежде чем передать второй стороне.

В целях аутентификации пользователь может задействовать протокол дву-

стороннего обмена открытыми ключами. Прежде всего, необходимо сгене-

рировать открытый и закрытый ключи шифрования:

> ssh-keygen

Initializing random number generator...

Generating p: ++ (distance 616)

Generating q: ++ (distance 244)

Computing the keys...

Testing the keys...

Key generation complete.

Enter file in which to save the key (/home/craig/.ssh/identity):

Enter passphrase: Pdky&tiaj.

Enter the same passphrase again: Pdky&tiaj.

Your identification has been saved in /home/craig/.ssh/identity.

Your public key is:

1024 35 158564823484025855320901702005057103023948197170850159592181522

craig@horseshoe

Your public key has been saved in /home/craig/.ssh/identity.pub

Команда ssh-keygen создает ключи. Наберите пароль (или «ключевую фра-

зу») не менее 10 символов длиной. При выборе легко запоминаемого пароля

воспользуйтесь приведенными ранее правилами. Если вы забудете ключе-

вую фразу, никто не сможет ее восстановить.

Создав ключи на клиентской системе, скопируйте открытый ключ на сер-

вер. В исходном каталоге клиента ключ хранится в файле .ssh/identity.pub.

Скопируйте его в подкаталог .ssh/authorized_keys своего исходного каталога

на сервере. Теперь при обращении к системе посредством ssh пользователю

предлагается набрать ключевую фразу:

> ssh horseshoe

Enter passphrase for RSA key 'craig@horseshoe': Pdky&tiaj.

Last login: Thu Sep 25 17:11:51 2001

458

Глава 12. Сетевая безопасность

Из соображений безопасности г-команды следует отключать после установ-

ки SSH. Закомментируйте

rshd,

rlogind, rexcd и rexd в файле inetd.conf, чтобы

заблокировать входящие обращения к r-командам. Чтобы наверняка ис-

пользовать SSH для исходящих соединений, замените rlogin и rsh на ssh.

С этой целью сохраните копии исходных программ rlogin и rsh в надежном

месте, выполните configure повторно - со специальными ключами, приве-

денными в примере, а затем выполните make install:

# whereis rlogin

/usr/bin/rlogin

# whereis rsh

/usr/bin/rsh

# cp /usr/bin/rlogin /usr/lib/rlogin

# cp /usr/bin/rsh /usr/lib/rsh

# ./configure --with-rsh=/usr/bin --program-transform-name='s/ s/r/'

ft make install

В данном примере предполагается, что исходные программы rlogin и rsh

хранятся в каталоге /usr/bin. Воспользуйтесь соответствующим именем ка-

талога для своей системы.

Заменив rlogin и rsh, вы по-прежнему можете работать с системами, не под-

держивающими SSH, однако при этом будете получать уведомление, что со-

единение не является защищенным:

> rlogin cow

Secure connection to cow refused; reverting to insecure method.

Using rsh. WARNING: Connection will not be encrypted.

Last login: Wed Sep 24 22:15:28 from rodent

SSH - прекрасный способ защищенного сообщения систем по сети Интернет.

Однако он требует установки пакетов SSH на обеих сообщающихся систе-

мах. Разумеется, это не проблема, если вы имеете административный доступ

к обеим системам. Но в некоторых случаях необходимо работать с системы,

которая управляется не вами. И тогда несомненно важными остаются одно-

разовые пароли, вроде тех, что предлагает OPIE.

Безопасность приложений

Аутентификация - важный механизм обеспечения безопасности. Но эта ме-

ра - лишь одна из многих, позволяющих повысить защищенность компью-

тера и сети в целом. Большинство успешных атак основано на использова-

нии ошибок в программном обеспечении либо ошибок в настройке про-

граммного обеспечения. В этом разделе мы рассмотрим способы улучшения

защищенности приложений.

Удаляйте ненужные программы

Любая программа, принимающая внешние соединения, потенциально мо-

жет стать каналом для атаки злоумышленника. Некоторые специалисты по

Безопасность приложений

459

безопасности рекомендуют удалять из файла /etc/inetd.conf настройки всех

демонов, которые не являются абсолютно необходимыми. (Работа с файлами

inetd.conf и /etc/xinetd.conf описана в главе 5, там же приводятся примеры

удаления службы tftp.)

Серверным системам требуется присутствие ряда демонов, но большинству

рабочих станций демоны не нужны в принципе либо нужны в ограниченных

количествах. Удаление демонов в файле inetd.conf блокирует только входя-

щие соединения, но не исходящие. Пользователь по-прежнему может обра-

титься к удаленной системе при помощи telnet, даже если демон telnet за-

блокирован в файле inetd.conf локальной системы. Простейший подход -

удалить все настройки из файла inetd.conf, а затем добавлять настройки

лишь тех демонов, которые действительно необходимы.

Обновляйте программы

Поставщики систем часто выпускают новые версии сетевых программ с

единственной целью - улучшить безопасность сетей. Используйте самые

свежие версии сетевых программ от поставщика системы. Отслеживайте

предупреждения, связанные с безопасностью и бюллетени CERT, чтобы

знать, какие именно программы особенно важно обновить.

Отставание в обновлении программного обеспечения открывает широкие

возможности для злоумышленников. Большинство из них пользуются ши-

роко известными уязвимостями, а вовсе не занимаются поиском новых. Сле-

дите за тем, какие проблемы безопасности обнаружены, чтобы вовремя об-

новлять свю систему.

Осведомленность о самых свежих «заплатах» для вашей системы не будет

лишней - пользуйтесь бюллетенями по безопасности. Свяжитесь с постав-

щиком/разработчиком системы и выясните, какие услуги по распростране-

нию обновлений он предлагает. Позаботьтесь о том, чтобы ваша заинтересо-

ванность в безопасности стала для него очевидной.

На рис. 12.2 представлен список программных обновлений, расположенный

на веб-сайте Red Hat. Переход по ссылке любого из перечисленных обновле-

ний позволяет получить описание проблемы, а также ссылку на обновление,

позволяющее от проблемы избавиться.

Ресурсы, подобные описанному, очень важны для поддержания актуальнос-

ти программного обеспечения. Чтобы эти ресурсы стали эффективным сред-

ством, их следует использовать. Администраторы часто жалуются, что раз-

работчики не спешат устранять проблемы, и, конечно, во многих случаях

это справедливо. Однако гораздо более распространенная проблема связана с

тем, что системные администраторы не устанавливают доступные обновле-

ния. Уделяйте определенное количество времени установке обновлений и

делайте это ежемесячно.

Службы обновления ПО, подобные Сети Red Hat (Red Hat Network), потен-

циально способны облегчить тяжелое бремя обновления программ. Служба

460

Глава 12. Сетевая безопасность

Рис. 12.2. Обновления от поставщика системы

обновления ПО позволяет разработчику системы периодически обновлять

системные программы по сети. Получит ли такая методика признание - воп-

рос пока еще открытый. Потенциально службы могут улучшить безопас-

ность и сократить работу по администрированию, но многие администрато-

ры не согласны на утрату полного контроля, связанную с передачей полно-

мочий на обновление сторонней организации.

Наблюдение за безопасностью

Ключевым элементом качественной системы обеспечения безопасности яв-

ляется наблюдение. Высокий уровень защищенности требует регулярного

проведения сопутствующих мероприятий, и приведенные выше рекоменда-

ции - только начало. Необходимо, помимо прочего, контролировать систе-

мы на предмет обнаружения несанкционированной активности, равно как и

обнаружения и удаления уязвимостей. Система меняется с течением време-

ни - активные учетные записи становятся пассивными, происходит смена

прав доступа для файлов. Необходимо отслеживать и разрешать подобные

проблемы по мере их возникновения.

Наблюдение за безопасностью

461

Познайте свою систему

Контроль безопасности в сети - это изучение файлов и журналов отдельных

систем сети. Чтобы обнаружить необычную активность, необходимо, преж-

де всего, знать, какая активность системы нормальна. Какие процессы

обычно работают в системе? Какие пользователи? Кто обычно работает с сис-

темой после окончания рабочего дня? Следует знать все это и многое другое о

системе, чтобы обрести «ощущение» того, как должны обстоять дела. Обще-

известные команды Unix ps и who помогают узнать, что для вашей системы

является нормальной активностью.

Команда ps отображает состояние процессов, запущенных в данный момент.

Периодическое выполнение ps позволяет получить четкую картину процес-

сов, работающих в системе в различное время суток, а также информацию о

том, кому принадлежат процессы. Команда Linux ps -au и команда Solaris ps

-ef отображают для каждого процесса сведения о пользователе и команде,

создавшей процесс. Этой информации вполне достаточно, чтобы понять, кто

с чем работает и в какое время. Заметив нечто необычное, потрудитесь про-

вести расследование. Убедитесь, что понимаете, каким образом использует-

ся ваша система.

Команда who перечисляет пользователей, работающих в системе в данный

момент. Для каждого пользователя отображается имя, устройство термина-

ла, время входа в систему и, если возможно, координаты удаленного узла,

с которого инициирован сеанс работы. (Команда w, вариант who, доступный в

некоторых системах, указывает также активный процесс для каждого из

пользователей.) Команда who позволяет понять, кто обычно работает с систе-

мой, а также с каких внешних узлов пользователи проводят сеансы работы.

Проводите расследования по любым отклонениям от нормы.

Если любая из этих стандартных проверок дает основания подозревать нали-

чие проблем с безопасностью, изучите систему на предмет присутствия не-

обычных или измененных файлов, файлов, которые должны существовать,

но не существуют, а также на предмет необычной активности пользовате-

лей. Столь пристальное изучение системы может производиться и при помо-

щи стандартных команд Unix. Команды и файлы, которые мы обсудим, при-

сутствуют в полном составе не во всех системах, однако в каждой операци-

онной системе есть определенные инструменты, помогающие внимательно

следить за тем, как используется компьютер.

В поисках неприятностей

Злоумышленники часто оставляют после себя файлы или сценарии, позво-

ляющие им повторно войти в систему либо получить полномочия админист-

ратора. Используйте команду Is

-а |

grep

•

для поиска файлов с именами,

начинающимися с точки (,). Злоумышленникам особенно нравятся такие

имена, как . mail,

. хх,

... (три точки), . . (точка, точка, пробел) или же ,

(точка, точка, <Ctrl>+<G>).