Безопасность данных в OC Unix

В ноябре 1988 года компьютерный червь, написанный студентом последнего курса Корнеллского университета Робертом Моррисом, в течение двух суток поразил около 6000 компьютеров. Пострадали вычислительный центр НАСА и Лос-Аламасская национальная лаборатория, система Агенства национальной безопасности, десятки университетских и академических центров... Подключенные к Internet системы один за другим были парализованы. Вирус достиг Европы и Австралии. Величайшее нападение продемонстрировало уязвимость Unix-компьютеров, пользователи которых пренебрегали требованиями безопасности.

Введение

Первоначально разработанный как чисто исследовательское системное окружение, Unix в первое время располагал только рудиментарными возможностями защиты информации. Упор делался вовсе не на безопасность пользовательских приложений, а на гибкость, открытость и максимальное удобство среды разработки.

Благодаря этим достоинствам ОС Unix и стала столь популярной и широко распространенной операционной системой.

С другой стороны, вопросы защиты информации сегодня попадают в центр внимания правительств, деловых кругов и производителей. Естественно, особое значение вопросам безопасности данных придают правительства и военные. Так, в США за несколько последних лет принята масса федеральных законов, правительственных постановлений, директив различных агентств, ведомственных протоколов и технических спецификаций, посвященных этой проблеме. Коммерческие потребители также осознали необходимость защищать ценную информацию.

Рост популярности Unix и все большая осведомленность о проблемах безопасности привели к осознанию необходимости достичь приемлемого уровня безопасности ОС, сохранив при этом мобильность, гибкость и открытость программных продуктов. Уровень безопасности, который должен удовлетворять нуждам правительственных учреждений и коммерческих потребителей, закреплен в различных стандартах.

Управление доступом в традиционном Unix'е

Прежде чем анализировать нововведения в механизме защиты, реализуемом современными версиями ОС, коротко скажем о том, что обеспечивает "традиционный" Unix (в первую очередь имеются в виду различные диалекты System V Release 3).

Итак, операционная система UNIX обеспечивает многопользовательский режим работы на компьютере. Каждый зарегистрированный пользователь имеет входное имя. пользователь с входным именем root называется суперпользователем; он имеет права на любые действия. Другие пользователи называются обычными.

Для входа в систему нужно в ответ на приглашение

   login:

ввести свое входное имя (и, быть может, пароль).

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

   passwd

Команда запрашивает у обычных пользователей старый пароль (если он был), а затем дважды запрашивает новый. После первого запроса, как правило, делается проверка на соответствие нового пароля техническим требованиям (например, пароль должен содержать не менее шести символов, в числе которых обязательно должны быть буквы, цифры и знаки). Когда новый пароль вводится во второй раз, две копии нового пароля сравниваются. Если они не совпали, цикл запроса нового пароля повторяется.

Каждый пользователь OC UNIX принадлежит некоторой группе. И входному имени, и имени группы соответствуют числовые идентификаторы (номера пользователя и группы), которыми система оперирует во всех случаях, кроме первоначальной идентификации пользователя.

Файловая система OC UNIX имеет иерархическую структуру. Выделен корневой каталог, содержащий файлы и другие каталоги. Последние, в свою очередь, содержат файлы и каталоги, и т.д.

По отношению к конкретному файлу все пользователи делятся на три категории:

• владелец файла
• члены группы владельца
• прочие пользователи

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

• Право на чтение
• Право на запись
• Право на выполнение ( для каталогов - право на поиск)

Указанных видов прав достаточно, чтобы определить допустимость любой операции с файлами. Например, для удаления файла необходимо иметь право на запись в соответствующий каталог.

Аналогично устроено управление доступом и к другим ресурсам ОС: очередям сообщений, семафорам и т.д.

Особое место занимают выполняемые файлы, принадлежащие пользователю root, в режиме доступа к которым взведен бит переустановки действующего идентификатора пользователя. Из назначение - предоставить привилегии суперпользователям для выполнения строго определенных действий. Будем называть подобные файлы ДИС-файлами. Типичным примером ДИС-файла служит /bin/passwd, c помощью которого любой пользователь может изменить системный файл паролей, однако изменение заведомо коснется только информации о данном пользователе, после чего файл паролей останется в корректном состоянии.

Следует учитывать, что ДИС-файлы могут превратиться в троянских коней, если кто-либо, кроме пользователя root, имеет право на запись в них. Действительно, появляется возможность скопировать в ДИС-файл произвольную программу, после чего о защите компонентов системы от несанкционированного доступа говорить не приходится. Нарушится защита и в том случае, когда программа, хранящаяся в ДИС-файле, предоставляет слишком широкие возможности. Например, если сделать ДИС-файлом /bin/sh, на компьютере просто не останется непривилегированных пользователей.

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

Утилита ps, будучи запущенной первый раз после загрузки системы, создает файл ps_data в каталоге /etc. Поскольку ps может вызвать любой пользователь, а права на запись в каталог /etc всем явно давать нельзя, следует прибегнуть к помощи бита переустановки действующего идентификатора группы. В результате файлы /bin/ps и /etc должны иметь следующие режимы доступа:

   -rwxr-sr-x   1 bin  sys  19300 Jan 25  1990 /bin/ps
   drwxrwxr-x  12 root sys  2256 Aug 2  18:47 /etc 
 

то есть каталог /etc должен принадлежать группе sys, с правом записи для членов группы.

Недостаточность механизмов традиционного Unix`а.

От всех современных мультипользовательских систем требуется предоставление некоторой степени безопасности. Традиционный Unix - тоже, однако, наличие весьма чувствительных данных или активных злонамеренных пользователей требует более убедительного набора возможностей защиты. Как раз здесь регулярный Unix чувствует себя неуверенно.

Регулярный Unix не содержит внятного механизма, который гарантировал бы сохранность пользовательских программ, файлов и системных ресурсов. В регулярном Unix`е есть несколько уязвимых с точки зрения безопасности мест, хорошо известным искушенным пользователям, вытекающими из самой природы UNIX и открывающими двери для нападения. Однако, хорошее системное администрирование может ограничить эту уязвимость.

Например, традиционный Unix не обеспечивает контроль доступа, способный разрешить/запретить доступ для конкретного пользователя. Хотя он обеспечивает доступ, основанный на понятиях группы и владельца, нет механизма, запрещающего доступ для группы или отдельного пользователя. Например, нельзя указать, что данный пользователь имеет право только читать файл, хотя все остальные члены его группы имеют право на чтение и запись.

Регулярный Unix также не ограждает пользователей, создающих файлы и каталоги. Неаккуратные пользователи могут установить подразумеваемый режим доступа к файлам, обеспечивающий общий доступ, в то время как предполагается монопольный.

Unix очень просто позволяет получить привилегии суперпользователя. Суперпользователь же имеет полный доступ к данным всех пользователей, системным программам, другим системным ресурсам. Системный администратор должен предпринять определенные усилия, чтобы ограничить возможности суперпользователя (нерадивые администраторы, к сожалению, встречающиеся часто, этого не делают).

Регулярный Unix не имеет действенных средств учета. Если нет соответствующих средств проверки полномочий, очень трудно определить, какой пользователь (какая программа) обращался к критичным ресурсам.

Поиск стандартов

В последние несколько лет главные производители Unix-систем произвели защищенные версии ОС. Число производителей аппаратного и программного обеспечения растет, и все они сегодня интересуются стандартизованными требованиями безопасности Unix.

Стандарты NCSC

Среди организаций, занимающихся стандартизацией в области защиты информации, наиболее широко известен Национальный Центр Компьютерной Безопасности Министерства Обороны США (US DoD`s National Computer Security Center - NCSC). NSCS руководствуется изданными в 1083 году Критериями Оценки Надежных Компьютерных Систем (TCSES - Trusted Computer System Evualation Criteria). Это документ часто называют Оранжевой Книгой. Утвержденная в 1985 году в качестве правительственного стандарта, Оранжевая Книга определяет основные требования и специфицирует классы для оценки уровня безопасности готовых и коммерчески поддерживаемых компьютерных систем. Используя Критерии, NSCS тестирует эффективность механизмов контроля безопасности. Критерии делают безопасность величиной, допускающей измерение, и позволяют покупателю в точности указать требуемый уровень безопасности. Подобная возможность эмпирического анализа безопасности систем привела к международному признанию федерального стандарта США.

NSCS считает безопасной систему, которая "посредством специальных механизмов защиты контролирует доступ к информации таким образом, что только имеющие соответствующие полномочия лица, или процессы, выполняющиеся от их имени, могут получить доступ на чтение, запись или удаление информации".

Иерархия классов безопасных систем

Иерархия надежных систем, приведенная в Оранжевой Книге, помечает низший уровень безопасности как С, высший - как А, промежуточный - как В. В класс D попадают системы, оценка которых выявила их несоответствие требованиям всех других классов. Основные возможности, характерные для С-систем - подсистема учета и избирательный контроль доступа (т.е. средства как наделять, так и лишать привилегии доступа каждого пользователя в отдельности). В-системы концентрируются на помеченных данных и распределении пользователей по категориям (мандатный контроль доступа). Каждому пользователю присваивается рейтинг защиты и он может получать доступ к данным только в соответствии с этим рейтингом. Класс А предлагает наличие формальных методов верификации вышеупомянутых средств.

Различные коммерческие структуры (например, банки) особо выделяют необходимость учетной службы, аналогичную той, что предлагают государственные рекомендации С2. Любая деятельность, связанная с безопасностью, может быть отслежена и тем самым учтена. Это как раз то, что требует С2, и то, что обычно нужно банкам.

Отмечается, правда, и еще одна особенность. Коммерческие пользователи, как правило, не хотят расплачиваться производительностью за завышенный уровень безопасности. А-уровень безопасности занимает своими управляющими механизмами доя 90% времени компьютера. Такие пользователи еще согласились бы с довольно большими накладными расходами на поддержание В-, но не А-уровня.

Более безопасные системы не только снижают эффективность, но и существенно ограничивают число доступных прикладных пакетов, которые соответствующим образом могут выполняться в подобной системе. Например, для обычного Solaris`а (современная версия Ос Unix производства фирмы Sun) есть несколько тысяч приложений, но для его аналога В-уровня - только сотня.

Приложения должны сопоставляться с ограничениями безопасных систем, иначе безопасность теряет смысл. Хотя большинство коммерческих потребителей удовлетворяется вполне определенным (и небольшим) подмножеством возможностей, данное ограничение все же существенно.

Примеры безопасных версий ОС Unix

AT&T System V/MLS была первой версией Unix`а, аттестованной NCSC как принадлежащая к классу В1 (это произошло в 1989 году). SunOS MLS - также пример операционной системы класса В1.

Большинство версий ОС Unix ориентируются на требования С2, что удовлетворяет потребности основной массы коммерческих пользователей. По данным Sun, более половины государственных контрактов этой фирмы на 1992-93 годы ограничиваются уровнем С; банки на уровень В и не заглядывают. Эксперты Sun предполагают, что В-уровень будет нужен десяткам, сотням, но не тысячам пользователей.

Операционные системы Solaris 2.0 и SCO Unix предоставляют возможности уровня С2. Unix SVR4.2 и HP-UX 9.0 - кандидаты в класс В2.

Средства обеспечения безопасности уровня С2

Механизмы обеспечения безопасности разных версий Unix во многом схожи. Рассмотрим подробнее одну из них - SCO Unix, по всей видимости, наиболее доступную в России Unix-систему современного образца. Данная система спроектирована в соответствии с требованиями уровня безопасности С2 по Оранжевой Книге.

Основные концепции

TCB (Trusted Computing Base) - набор программ, управляющих частями системы, ответственными за безопасность. ТСВ состоит из ядра ОС Unix и утилит, работающих с данными подсистемы безопасности. ТСВ реализует политику обеспечения безопасности системы. Данная политика - это множество правил надзора и охраны взаимодействий между субъектами (процессы) и объектами (файлы, устройства, ресурсы межпроцессорного взаимодействия). Для С2-уровня политика состоит из Избирательного Контроля Доступа (DAC - Discretionary Acces Control) и из требования о том, что перед размещением объектов необходимо очищать отведенное под них пространство.

Подотчетность. Действие подотчетно, если его можно проследить для конкретного лица. В надежных системах можно отследить ответственного за любое действие. В большинстве Unix-систем это не так. Например, lp выполняется анонимно. Надежный Unix повышает подотчетность путем установления соответствия между всеми входами в систему и реальными пользователями, учета каждого действия и сопоставления каждого действия конкретному пользователю.

Как уже говорилось, в типичном Unix`е каждый процесс имеет реальный и действующий идентификаторы пользователя (то же самое для группы). Процесс с действующим идентификатором суперпользователя может произвольным образом эти идентификаторы изменить. Уровень С2, однако, требует, чтобы ТСВ могла уникальным образом идентифицировать каждого пользователя. Для этого в надежных Unix-системах вводится еще один идентификатор пользователя - входной. Это несмываемый штамп для каждого процесса, он не изменяется в течение всего сеанса работы; порожденные процессы наследуют LUID у предка.

Избирательный Контроль Доступа. DAC определяет, имеет ли пользователь доступ к требуемым данным. В большинстве Unix-систем защита основывается на понятиях владельца и группы и режимов доступа к объектам. Надежный Unix расширяет стандартный механизм, ограничивая для пользователя возможности:

• устанавливать бит переустановки идентификатора
• изменять владельца файла
• злоупотреблять битами переустановки и битом "несговорчивости" (эти биты сбрасываются, если файл модифицируется; т.о. пользователь не может подменить программу)

Бит "несговорчивости" для каталогов означает, что удалять файлы из этого каталога может только его владелец и суперпользователь; установить данный бит может только суперпользователь.

Полномочие - атрибут пользователя, требующийся для выполнения определенных действий. Большинство Unix-систем принимают решения о возможности доступа на основании простых прав доступа; процессы суперпользователя всегда получают доступ. TCB выделяет два типа полномочий: полномочия ядра и полномочия подсистем. Полномочия ядра ассоциируются с процессами. Они позволяют процессу выполнить определенные действия, если процесс обладает необходимой привилегией. Полномочия подсистем ассоциируются с пользователями. Они позволяют пользователю выполнять определенное действие посредством команд, отнесенных к подсистеме. Подсистема - набор файлов, устройств и команд, служащих определенной цели. Например, подсистема lp состоит из файлов накопления печати, принтеров и команд типа lpadmin(ADM).

Полномочия ядра заносятся в "множество полномочий", ассоциированное с каждым процессом. Полномочия устанавливаются по умолчанию; пользователь может их и переустановить.

Идентификация и проверка подлинности. Когда пользователь входит в ненадежную ОС, имеет мето ограниченная идентификация и проверка подлинности^* . Система по входному имени проверяет пароль в базе данных паролей /etc/passwd. Если имя найдено, система опознает пользователя путем зашифрованного пароля с содержимым соответствующего поля в базе данных паролей.

Надежная система расширяет стандартный механизм. Есть определенные правила, ограничивающие допустимые пароли, новые процедуры для генерации и изменения паролей. Расположение и защита определенных частей базы данных паролей изменены. Администратор имеет больший контроль над процессом входа. Этот аспект системы поддерживает отдельный пользователь - администратор опознавания (полномочие подсистемы auth.

Учет. Большинство Unix-систем ограничено поддерживают записи о действиях системы. Система подотчетности делает одну запись после завершения каждого пользовательского процесса. Надежная ОС предоставляет полный "след" действий - журнал учета. Журнал содержит в себе записи о каждой попытке доступа субъекта к субъекту ( и успешные, и неудачные), о каждом изменении субъекта, объекта, характеристик системы. Подсистема учета управляется специальным администратором учета (полномочие audit). Администратор учета решает, как много информации записывается, насколько надежно, и управляет собранной информацией. Информация помогает администратору выяснить, что случилось с системой, когда и кто в этом участвовал.

Защищенные подсистемы. Unix-системы обеспечивают механизм переустановки идентификаторов пользователя или группы. Это позволяет конструировать программы, имеющие дело с приватной информацией: доступ к ней возможен посредством только операций, предусмотренных в этих программах. TCB определяет несколько защищенных подсистем. Каждая состоит из набора приватной информации устройств и утилит. Надежная система расширяет понятие защищенной подсистемы:

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

Функционирование надежной системы

В надежной Unix-системе административные задачи разделены на несколько различных ролей; каждая из них может быть поручена одному лицу или разным. Каждой роли соответствуют отдельные полномочия; такое соответствие помогает отслеживать происходящее. В соответствии с распределение административных ролей устанавливаются следующие полномочия ядра:

• configaudit (право модификации параметров учета)
• writeaudit (право записи в журнал учета)
• execduid (право выполнять программы с битом переустановки)
• chmodsugid (право устанавливать бит переустановки)
• chown (право изменять владельца объекта)
• suspenaudit (приостановка учета процесса)

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

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

Администратор опознавания может позволять пользователям самостоятельно вводить пароли или использовать сгенерированные пароли. Пароль может подвергаться проверке на очевидность. Для паролей контролируется "время жизни"; выделяются следующие состояния:

• пароль корректен
• пароль просрочен (пользователь может войти в систему и изменить пароль - если у него есть на это полномочие)
• пароль мертв (пользователь заблокирован; необходима помощь администратора)

Пользователи часто пытаются сопротивляться принудительной периодической смене паролей, немедленно восстанавливая предыдущее значение. Чтобы помешать этому, кроме максимального устанавливается еще и минимальное время жизни паролей.

Терминал - это дверь в систему. терминалы могут быть защищены от попыток вторжения в систему. Можно установить максимальное число неудачных попыток входа в систему. После того, как это число исчерпано, терминал блокируется; разблокировать его может только администратор. Кроме того, можно специфицировать интервал между двумя попытками входа.

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

Если пользователь в течение длительного времени не вводит никаких команд, он, скорее всего, закончил работу и просто забыл выйти из системы. надежная система позволяет специфицировать отрезок времени, по истечении которого бездействующие пользователи принудительно "выводятся" из системы.

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

Импорт файлов и файловых систем, если он осуществляется неаккуратно, может представлять угрозу для системы. Следует контролировать режимы доступа и владельцев импортируемых файлов. Поврежденные файловые системы при монтировании могут привести к разрушению системы перед первым монтированием обязательно должны быть проверены.

Выявление вторжений в систему

Ни одна система не является абсолютно безопасной. Риск минимизируется; однако, надо уметь обнаруживать вторжения, имевшие место. Возможны следующие пути вторжений:

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

Как выявить подобные ситуации?

Украденные пароли. При каждом входе в систему показывается дата и время предыдущего входа. Если это время отличается от того, что помнит пользователь, значит, его пароль кто-то украл. Администратору следует приучить пользователей сообщать ему о всех таких случаях. Администратор должен следить за сменой паролей и запрещать входы в систему без паролей. Полезной также является информация о неудачных попытках входа в систему.

Злоупотребление привилегиями. Если есть причины подозревать лицо, имеющие полномочия суперпользователя в злоупотреблении привилегиями, следует включить для этого пользователя процедуру учета, чтобы определить, выполняет ли он подозрительные действия.

Неконтролируемый доступ к компьютеру. Первейшее требование безопасности - предотвратить неконтролируемый доступ к компьютеру. Опасно предоставлять оборудование для открытого доступа пользователям. Любые средства защиты системы будут бесполезны, если оборудование, носители сохраненных версий и дистрибутивы не защищены. Если в системе в момент проникновения никто не работает, такой доступ может остаться незамеченным. Проявиться такое вторжение может в сообщениях о входе под именем суперпользователя, подозрительные действия суперпользователя, необъяснимые перезагрузки системы в журнале учета. Лучшее решение все же - запереть компьютер на ключ. Необходимо защитить сам компьютер, линии коммуникаций (UUPC, Ethernet, терминалы), дистрибутив, дискеты и ленты сохранности от несанкционированного доступа.

Использование подсистемы учета

Подсистема учета регистрирует происходящие в системе события, важные с точки зрения безопасности, в журнале учета, который впоследствии можно анализировать. Журналы учета помогают выявить случаи проникновения в систему и злоупотребления ресурсами.

Учет позволяет анализировать собранную информацию, выявляя способы доступа к объектам и действия конкретных пользователей. Подсистема учета с большой степенью надежности гарантирует, что попытки обойти механизм защиты и контроля полномочий будут учтены. Пользователи, совершающие некорректные действия, будут обязательно выявлены; подсистема учета служит для них устрашением.

Классификация пользовательских действий по типам основывается на выполняемых системных вызовах. Один их типов событий, DAC Denial, регистрирует неудачные, из-за отсутствия необходимых прав, попытки доступа. При анализе журнала учета администратор легко обнаружит повторяющиеся попытки доступа к недоступным файлам - сигнал тревоги о возможном проникновении.

Существенный фактор действенности подсистемы учета - однозначная индентификация действий каждого пользователя на основании его входного идентификатора LUID.

Базовый механизм учета генерирует записи учета слоя системных вызовов. Каждому системному вызову соответствует элемент особой таблицы, определяющий, существенен ли данный вызов для безопасности системы и какому типу событий он соответствует. кроме того, дополнительные записи генерируются по таблице кодов ошибок. Базовый механизм учета делает внутреннее обращение к драйверу учета, чтобы сделать запись в журнал учета.

Например, системный вызов open классифицируется как событие Make object available. При успешном завершении данного вызова генерируется соответствующая запись. Однако, если системный вызов завершился неудачей из-за недостаточных прав доступа к файлу, действие классифицируется как DAC Denial. Одному системному вызову может соответствовать несколько типов событий; с другой стороны, можно учитывать события только определенных типов. Подсистема учета регистрирует события выборочно, в соответствии с маской учета. Для каждого процесса маска определяется по маске учета, заданной для каждого пользователя, и по системной маске учета. Выбор конкретной маски учета - это всегда компромисс, принимающий во внимание, с одной стороны, надежность и эффективность работы системы, и ее безопасность, с другой.

Некоторые системные вызовы с точки зрения безопасности несущественны. Пример: вызов getpid (значение идентификатора процесса).

Драйвер учета управляет интерфейсными устройствами подсистемы учета. Один из них - /dev/auditr - используется исключительно демоном учета auditd для чтения записей сборных файлов подсистемы учета. Другое устройство - /dev/auditw - используется прикладными программами, имеющими достаточно полномочий, чтобы делать записи в подсистему учета; оно может быть одновременно открыто несколькими программами. Особый драйвер необходим, поскольку подсистема учета по соображениям эффективности использует не стандартный "файловый", а специфический метод доступа к специально отведенной под журнал учета области диска.

Демон учета запускается, как только начинает работу учетная подсистема. Учетная подсистема непрерывно генерирует записи и заносит из в сборные файлы учета. В каждый момент может существовать много сборных файлов учета, так как подсистема постоянно переключается на новые файлы, чтобы ни один из них не стал слишком большим. Демон отвечает за чтение записей из сборных файлов учета и их уплотнение.

Безопасность и сетевая обработка

Сети полностью видоизменили использование компьютеров. Они позволяют за секунды обмениваться информацией. Но они по-новому ставят и вопросы безопасности.

Сетевые серверы - это ворота, через которые внешний мир получает доступ к информации на Вашем компьютере. Поэтому каждый сервер должен:

• определить, какую информацию/действие запрашивает клиент;
• решить, имеет ли клиент право на информацию (быть может, дополнительно опознавая личность [или программу], которая запрашивает сервис);
• передать требуемую информацию/выполнить действие.

Многие серверы требуют привилегии root. Ошибки в сервере и "черные ходы" могут подвергнуть опасности защиту всего компьютера, открывая систему любому пользователю в сети, осведомленному об изъяне. Даже относительно безобидная программа может привести к разрушению всей системы. Изъяны могут оставаться в программах, многие годы распространяемых производителем, и обнаруживаться в будущем.

Возможно, наиболее известный пример - ошибка в демоне /etc/fingerd, одна из двух лазеек, найденных Робертом Моррисом. Исходный текст программы содержал следующие строки:

char line[512];
line[0]=``;
gets(line);

Поскольку переполнение буфера не проверялось, кадр стека можно было разрушить. Моррис написал код, заставлявший fingerd выполнять shell (естественно, от имени суперпользователя).

К сожалению, таят в себе опасности и такие употребительные сетевые сервисы, как ftp и telnet. ftp позволяет передавать файлы по сети. Обычно, чтобы получить доступ к удаленному компьютеру, надо указать имя и пароль. В момент передачи по сети эту информацию можно перехватить. Например, Ethernet передает пакеты по шине; обычно узлы сети запрограммированы таким образом, чтобы получать пакеты, доступные только для них. Но их можно перепрограммировать так, чтобы "слышать" все пакеты. Если подслушать, что передает соединение ftp (или telnet - удаленный виртуальный терминал), можно перехватить имя и пароль.

В последнее время активно развивается технология защиты в сети. Пересматриваются все сетевые протоколы. Особое внимание уделяется принципиально новой проблеме - опознаванию пользователя; уже предложен ряд технологий. Наиболее известная разработка - основанная на выделенном сервере опознавания система Kerberos. (Об этой и аналогичных технологиях мы расскажем в одной из будущих статей).

Заключение

Уроки величайшего компьютерного нападения не прошли даром. Разработанные версии ОС UNIX предоставляют эффективные средства обеспечения безопасности; исправлены многие ошибки. Системы поступают от производителя в более безопасном виде, чем раньше.

Однако все технические нововведения пойдут прахом, если пользователи и системные администраторы не овладеют современной технологией защиты. К сожалению, еще очень многие и не догадываются о том, что им надо думать о безопасности, выбирать подходящие пароли, выключать свои машины на ночь, наконец.