----------------------- | | | нуль-модем | | | v v | --------------- --------------- | | | | | переключатель | | переключатель | \ 1 / \ 2 / \___________/ \___________/ ^ ^ прямой | | прямой кабель | | кабель v v +-------------+ +-------------+ | | | | | UNIX | | UNIX | | Микро-ЭВМ 1 | | Микро-ЭВМ 2 | | | | | +-------------+ +-------------+ --------------------------------------------------------------------- Каждая микро-ЭВМ подсоединена к блоку переключения через главное соединение. Эти переключатели 1 и 2 коммутируются друг с другом и с блоком переключения 3. Микро-ЭВМ 1 может переключаться на микро-ЭВМ 2 в качестве интерфейса терминал/uucp и на главную машину в качестве удаленного терминала. В этом случае линия главной машины проходит через селектор порта. Микро-ЭВМ 2 может переключаться между микро-ЭВМ 1 и главной машиной аналогичным образом. Переключатель 3 коммутирует главную машину между микро-ЭВМ 1 и микро-ЭВМ 2. Возможны следующие комбинации: микро-ЭВМ 1 --> переключатель --> главная машина Зарегистрироваться в качестве удаленного терминала микро-ЭВМ 1 <-- --> переключатель <-- --> микро-ЭВМ 2 Обращение в UNIX или из UNIX в зависимости от getty микро-ЭВМ 2 <-- --> переключатель <-- --> микро-ЭВМ 1 Обращение в UNIX или из UNIX в зависимости от getty микро-ЭВМ 2 --> переключатель --> главная машина Зарегистрироваться в качестве удаленного терминала главная машина <-- переключатель <-- микро-ЭВМ 1 Зарегистрироваться с удаленного терминала главная машина <-- переключатель <-- микро-ЭВМ 2 Зарегистрироваться с удаленного терминала *** Вероятно, рассмотренные нами конфигурации могут не в точности соответствовать вашим потребностям. Однако мы представили их с той целью, чтобы вы увидели разнообразие типовых решений, которые вы можете адаптировать для себя. В следующей главе мы несколько отойдем от всех этих гаек и болтиков и подробнее рассмотрим вопросы, связанные с администрированием системы, особенно вопросы безопасности.  * ГЛАВА 9. Администрирование и безопасность *  ОБЯЗАННОСТИ И ОТВЕТСТВЕННОСТЬ АДМИНИСТРАТОРА ПОДДЕРЖКА БЕЗОПАСНОСТИ В СИСТЕМЕ ТИПИЧНЫЕ ПРОБЛЕМЫ БЕЗОПАСНОСТИ access показ всех беспарольных входов в систему chkset проверка наличия в системе файлов с разрешенной установкой идентификатора пользователя или группы suw отслеживание нарушителей по протокольному файлу команды su АДМИНИСТРИРОВАНИЕ И БЕЗОПАСНОСТЬ ЗАЧЕМ НАМ ИЗУЧАТЬ АДМИНИСТРИРОВАНИЕ ----------------------------------- Вашу карьеру в системе UNIX в качестве ученика (стать бы поско- рее мастером!) можно представить себе в виде трех ступеней квалифика- ции. Первая ступень - посвящение в работу системы UNIX в целом, осо- бенно изучение ее сердцевины - файловой системы. Первые три главы заложили этот фундамент и предоставили практические инструментальные средства для обслуживания системы. Вторая ступень мастерства - под- держка вашей собственной работы и персональной среды - рассматривает- ся в главах с четвертой по шестую. В главах 7 и 8 более подробно рассматриваются два специальных аспекта практической работы с систе- мой UNIX - устройства и коммуникации. Теперь мы готовы достичь третьей ступени мастерства - курировать работу самой системы, что более прозаически называется системным ад- министрированием. Если вы в настоящий момент такой пользователь, который занимает- ся программированием, или если вы все время работаете системным прог- раммистом, то вас может удивить, зачем вам становиться на точку зре- ния системного администратора и овладевать его основными инструментами работы. На это имеется две серьезные причины: знание и необходимость. Системное администрирование требует близкого знакомства с тем, где и что находится в системе, и понимания взаимосвязи конкретного процесса с системой в целом. Программисты стремятся нахвататься све- дений о чудесах и результатах таинственных команд и о всяческих хит- ростях, которые они считают полезными, но зачастую они не хотят тра- тить время на знакомство с системой UNIX в целом. Мы бы хотели сагитировать вас на более систематическое изучение системы UNIX с той целью, чтобы вы могли открыть для себя новые кладовые знаний. Вот по- чему на протяжении данной книги мы создавали инструментальные средс- тва, которые не только делают полезные вещи, но и помогают вам изу- чать саму систему. Необходимость знать администрирование становится ощутимой, когда вы обнаруживаете, что вам вдруг задали работу системного администра- тора или администратор ушел в отпуск, что пользователи выстроились возле ВАШЕГО стола в ожидании помощи, поскольку вас считают признан- ным авторитетом. Другой причиной возникновения необходимости может быть то, что вы стали безраздельным хозяином вашей собственной микро- ЭВМ с системой UNIX и хотите все установить и поддерживать по своему вкусу. Взгляните на такую необходимость администрирования как на воз- можность накопить обширные и доскональные знания о UNIX, которые мо- гут сослужить вам добрую службу в вашей будничной работе с компьюте- ром. Быть мастером UNIX - дело чести и технической грамотности. Пыта- ясь удовлетворить требованиям необходимости, мастера UNIX учатся пос- певать за потоком необходимых им знаний. Мастера UNIX не только хоро- шо играют, но и просчитывают игру на один ход вперед. НЕКОТОРЫЕ НАБЛЮДЕНИЯ ПОСВЯЩЕННОГО В АДМИНИСТРИРОВАНИЕ ----------------------------------------------------- Положение системного администратора таково, что требует более широкого понимания системы, чем необходимо пользователю или даже программисту, и в связи с этим большей ответственности. Способность всех, кто не сильно знает UNIX, выполнить свою работу, зависит от способности администратора поддерживать работоспособность системы, предвидя и разрешая проблемы до того, как они станут опасными. Одним из наиболее важных вопросов администрирования является бе- зопасность. Сведения о безопасности, представленные здесь, были на- коплены в результате работы с администраторами, работы в качестве ад- министратора и иногда необходимости работы при наличии несогласованно действующих администраторов. Помимо безопасности, рассмотрены некоторые из более общих вопро- сов деятельности администратора. Немногие руководства и книги учат, как быть администратором. Эти навыки в основном приходят с опытом. Ваша конфигурация системы, потребности пользователей и приоритеты все вместе оказывают влияние на то, как вы справляетесь с административ- ными задачами. Мы поможем вам показом инструментальных средств и трю- ков, рассказом историй о ловушках и капканах и рассмотрением различ- ных подходов, работающих в реальной практике. АДМИНИСТРАТИВНЫЕ ОБЯЗАННОСТИ ---------------------------- В большинстве больших компьютерных систем администраторы весьма уважаемые люди. Они отвечают за поддержание работоспособности вычис- лительной системы 24 часа в сутки, наращивание ее в случае необходи- мости, помощь пользователям в разрешении их проблем, патрулирование и обеспечение безопасности. Администрирование - это фактически несколь- ко разных работ в одной. Мы собираемся подробно рассмотреть каждую из этих областей, а затем предложить помощь и инструментальные средства для овладения администрированием. ПОДДЕРЖКА РАБОТОСПОСОБНОСТИ СИСТЕМЫ Поддержка работоспособности системы - приоритет номер один. Это означает нечто большее, чем просто избегать сокрушительных системных крахов, хотя важность их недопущения очевидна. Обеспечение работоспо- собности системы требует также профилактических мер. Одно из лучших занятий для вас после того, как вы завершите первое прочтение данной книги,- вернуться в ее начало и рассмотреть изложенные в ней идеи и инструментальные средства с точки зрения администратора. Например, рассмотрение того, как правильно реализовать резервное копирование файлов и сборку мусора (см. главу 3), может помочь предотвратить сис- темные крахи, вызванные условиями переполнения. Если же крах все-таки произойдет, то такое рассмотрение позволит вам восстановить все дан- ные настолько быстро и полно, насколько это возможно. УЛУЧШЕНИЕ СИСТЕМНЫХ ВОЗМОЖНОСТЕЙ По мере того, как все больше и больше людей эксплуатируют систе- му, требуется все больше ресурсов, но вы можете также найти способы использования имеющихся ресурсов с большей эффективностью. Разрабаты- вая способы повышения производительности системы, вы найдете для себя много полезного в инструментальных средствах, представленных в главе 3. В системе UNIX редко хватает принтеров, дисковых устройств, после- довательных портов, сетевого оборудования и т.п., но более эффектив- ное применение может помочь решить те же задачи без добавления новых ресурсов. По всей видимости, наиболее важным ресурсом является время цент- рального процессора. Посадите тридцать пользователей в системе, расс- читанной на двадцати четырех - и вы сразу почувствуете нехватку про- цессорного времени. В работу администратора входит поддержка текущих ресурсов, а также планирование роста системы на будущее. Поэтому тре- буется, чтобы вы знали типичные раскладки использования вашей систе- мы, знали, где могут возникнуть "узкие места", как эффективно распре- делить имеющиеся ресурсы и какие способы наращивания системы могут быть наиболее эффективными по стоимости. Некоторую полезную информа- цию можно извлечь путем "статического" инспектирования файловой сис- темы с помощью средств, представленных в главе 2. Более динамичную картину эксплуатации системы вы можете получить, применяя команду ps, чтобы увидеть, какие процессы активны в настоящее время, и применяя команду w (в системе Berkeley), которая выдает статистику загрузки системы и организации очередей. ПОМОЩЬ ПОЛЬЗОВАТЕЛЯМ Пользователи системы - несомненно, имеют высокий приоритет. Все в системе должно быть организовано так, чтобы они могли выполнить свою работу. Администратор должен следить за тем, чтобы все разумные (и некоторые неразумные) запросы пользователей удовлетворялись. В обслуживание потребностей пользователей может входить монтиро- вание лент и других файловых систем, резервное копирование файлов, отладка коммуникационных линий и заготовка персональных записей для пользователей в привилегированных файлах типа crontab и inittab. (Эти два файла дают пользователям больше гибкости в организации их среды и планировании задач, но при этом ощутимы также для прямого пользова- тельского доступа.) Это может показаться легким делом, но требует много времени. БЕЗОПАСНОСТЬ: НУЖЕН СТОРОЖЕВОЙ ПЕС Администратор ведает всеми вопросами безопасности. Обычно он единственный, кто занимается этой работой. Пользователи не обеспечи- вают безопасность, потому что они не умеют или не знают, как это сде- лать. Нарушители безопасности могут атаковать систему многими спосо- бами. Они могут занять системные ресурсы, заполняя таблицу процессов или таблицу открытых файлов и распределяя для себя все свободное дис- ковое пространство и все свободные индексные дескрипторы файлов. Они могут перепутаться с другими пользователями системы или поменять сис- темное время. Они могут повредить файлы данных или исполняемые модули и даже подделать почту. Но при вашей организации системы они чаще всего становятся просто "пользователями-хулиганами". Позже мы расс- мотрим более серьезные вещи, чем системное хулиганство - тех пользо- вателей, кто может несанкционированно воспользоваться правами супер- пользователя. Наилучший подход к проблемам безопасности - осознать, что дейс- твительно нуждается в защите, а не пытаться стать суперсыщиком. Вы должны особенно заботиться о нуждах системных программистов и других опытных авторитетов в вашей системе. В идеале администратор должен работать ВМЕСТЕ, а не против признанных авторитетов и поддерживать с ними хорошие деловые контакты. Не у всех нарушителей одинаковые моти- вы. Например, кто-то из авторитетов может захотеть получить доступ к правам суперпользователя для того, чтобы самостоятельно делать неко- торую работу, а не ждать, когда ее сделаете вы. Кто-то другой может быть обижен на кого-то или вообще на весь мир и стремится отомстить путем разрушения файлов. Каждая ситуация требует индивидуальной оцен- ки. Напомним, что разделяющая линия между администраторами и систем- ными авторитетами зачастую неопределенная и непостоянная. Безопас- ность иногда превращается в игру, в которой определенные пользователи пытаются разглядеть, чего они могут избежать, а администраторы пыта- ются сохранить контроль над системой. В работе сторожевого пса задействовано пять функций: 1. Защита от неразрешенных входов в систему, файлов, программ и команд su. 2. Сохранение конфиденциальности определенных данных. 3. Наблюдение за использованием модемов. 4. Предотвращение неразрешенных пересылок файлов. 5. Сведение к минимуму возможностей взлома. Здесь много работы! Система UNIX так обширна, и файлы могут скрываться в таком большом количестве мест, что один лишь поиск са- мозванцев занимает почти все время. Это требует от администратора не столько тяжелой, сколько изобретательной работы. Для того чтобы обес- печить себе шансы на победу в этой борьбе, вы должны сделать так, чтобы система помогала себя защищать. Несколько позднее в этой главе мы предложим инструментальные средства access и suw, которые помогают вам защищаться от запрещенных входов в систему, и командный файл chkset, имеющий дело с защитой конфиденциальных файлов. Мы также предлагаем более детальный взгляд на конкретные проблемы безопаснос- ти. ЗАЩИТА ОТ ЗАПРЕЩЕННЫХ ВХОДОВ В СИСТЕМУ, ФАЙЛОВ, ПРОГРАММ И КОМАНД su Имеется много способов получения несанкциониованных привилегий в системе UNIX. Самый простой способ - иметь корневой (суперпользова- тельский) интерпретатор shell. Это такой shell, который запускается как особо привилегированный процесс, имеющий возможность читать, уда- лять или модифицировать ЛЮБОЙ файл в системе независимо от того, ка- кие права доступа установлены для этого файла его владельцем. Корне- вой shell можно заполучить, узнав корневой пароль у неосторожного администратора или при помощи других средств, рассматриваемых ниже. Несанкционированный пользователь, имея доступ к правам супер- пользователя, может подготовить "потайные двери", обеспечивающие дальнейший запрещенный доступ. Они позволяют нарушителю запускать shell с корневыми привилегиями. Более подробно мы рассмотрим их позд- нее. Потайные двери могут выступать в различном обличье. Они могут быть исполняемыми модулями, латками в системных утилитах или латками в системных файлах. Администратор должен вести постоянное наблюдение за изменениями в системе и уметь противодействовать всяческим вмеша- тельствам. Ниже мы рассмотрим некоторые инструментальные средства и приемы, помогающие вам обнаруживать такое проникновение. ВХОДЫ В СИСТЕМУ Начнем с несанкционированных входов в систему. Это может прои- зойти многими способами. Бывает, что нарушитель добавляет свое собс- твенное регистрационное имя в парольный файл и помещает туда свой па- роль. Если администратор не знаком с парольным файлом или давно туда не заглядывал, то такую несанкционированную запись можно проглядеть. Другой метод несанкционированного входа в систему заключается в том, что кто-то может завладеть всеми паролями, вставляя в программу login "латку" с текстом, направлящим все введенные пользователями па- роли в потайной файл. Ниже мы рассмотрим некоторые типы таких "ла- ток". Конечно, такая изысканная работа зачастую совсем не обязательна. Как известно, люди оставляют свои пароли написанными на листках бума- ги в незапертых ящиках стола. Для некоторых верхом секретности явля- ется применение комбинации первого и последнего имени в качестве па- роля. Однако если уж нарушитель знает много паролей, он может применять каждый раз различные регистрационные имена, чтобы не попа- даться на опасном имени. Пробить систему защиты UNIX можно с помощью "исполняемых регист- рационных имен". Это имена, которые запускают программу, а не просто предоставляют вам shell, что является обычным способом начала сеанса работы пользователя в системе. Это может выглядеть примерно так: date::100:50:Print the date:/bin:/bin/date who::101:50:Print all logged on users:/bin:/bin/who Это может запустить любой, кто имеет доступ к терминалу или мо- демному порту. Иногда это правильные имена, например date, who или sync. Хотя для администратора может быть удобным наличие программ, запускаемых при входе в систему, они часто становятся лазейками, че- рез которые кто-нибудь может проникнуть в систему и обнаружить много информации о системе. Самые крупные лазейки появляются тогда, когда эти регистрацион- ные имена выполняют командные файлы интерпретатора shell. Как только нарушитель получает привилегии суперпользователя (даже если они лишь временные), он может поместить в парольный файл такую запись, которая в момент входа в систему запускает командный файл интерпретатора shell (или может изменить имеющуюся запись с командным файлом). Сами эти командные файлы можно в любой момент изменить так, чтобы они ра- ботали по заданию несанкционированного пользователя. Например, в па- рольном файле может быть такая запись: break::102:50::/:/usr/bin/break Такая запись позволила бы кому угодно набрать имя "break" в ответ на регистрационную подсказку, в результате чего выполнился бы файл /usr/ bin/break. Когда break отработает, снова поступает регистрационная подсказка, и в системе появляется новая лазейка. Почему? Потому что командный файл break может содержать команды для редактора, которые отредактировали бы парольный файл и добавили несанкционированные за- писи. Это становится возможным по той причине, что процесс getty (пе- чатающий регистрационную подсказку) запускается процессом init, а владельцем файла init является суперпользователь. Такая привилегия передается командному файлу, так как он запущен в момент регистрации в системе, а программам, запускаемым при входе в систему, обычно тре- буется суперпользовательский доступ для выполнения необходимых иници- ализаций. В данном случае, однако, он позволяет редактору читать файл /etc/passwd и писать в него. Таким образом, как только нарушитель ОДИН РАЗ получает доступ на запись в /etc/passwd (аналогично "дивер- сионным программам"), он может установить постоянный доступ, часто даже через несколько точек входа. И еще. В старых версиях UNIX попадаются некоторые ошибки, пре- доставляющие суперпользовательские возможности. Например, если в пользовательской записи парольного файла не указан номер пользова- тельского идентификатора, то по умолчанию он считается нулевым, т.е. суперпользовательским. В эту лазейку очень легко проникнуть. Пример такой записи: rt::::The Super User:/:/bin/sh Вот некоторые другие проблемы, за которыми должен следить адми- нистратор. Если первая строка парольного файла пустая, то пользова- тель может зарегистрироваться как корневой без пароля. Проверьте так- же запись "bin" в парольном файле, которая обычно запускает системные программы. Если запись bin не содержит пароля, как в приведенном выше примере, кто-то может войти в систему в качестве bin и отредактиро- вать файл crontab, чтобы применить к парольному файлу команду chmod (change permission mode, изменение прав доступа) и обеспечить себе доступ к нему. Пользователь bin может также отредактировать файл /etc /rc, чтобы сменить парольный файл. Файл rc используется для конфигу- рирования системы в момент ее старта путем автоматического запуска ряда программ. Все, что нужно для успешного вторжения,- подождать, когда администратор перегрузит систему (поскольку именно в этот мо- мент файл запускается). После перезагрузки нарушитель может войти в систему как обычный пользователь, отредактировать парольный файл, за- писать его, а потом в любой момент входить в систему в качестве су- перпользователя. Это всего лишь несколько способов, которыми можно добиться несанкционированного входа в систему. К сожалению, каждый день выдумывают новые способы. ФАЙЛЫ И ПРОГРАММЫ Еще одна сфера злоупотреблений связана с несанкционированным проникновением в файлы и программы. Самый трудный этап для того, кто хочет взломать защиту системы UNIX,- стать суперпользователем первый раз, но как только эта цель достигнута какими-либо средствами, файлы- интервенты можно поместить в любом месте системы. Вторжение может включать в себя размещение "потайных дверей", латание команды login с целью овладения паролями, чтение и изменение системных учетных файлов и т.д. Ниже мы рассмотрим примеры этих и других методов. Основными файлами, в которые вторгается корневой нарушитель, яв- ляются /etc/passwd, /etc/*rc*, /usr/lib/crontab, /usr/lib/uucp/L.sys. Для обнаружения трещин в вашей административной броне можно поискать файлы, для которых взведен бит разрешения установки пользовательского идентификатора (что указывается буквой "s" в правах доступа, отобра- жаемых командой "ls -l"), и файлы, владельцем которых является супер- пользователь. Назначение бита установки пользовательского идентифика- тора - разрешить программе иметь временный доступ к более привилегированному состоянию (например, суперпользовательскому), чем она имеет в момент своего запуска. На самом деле это очень полезное свойство системы UNIX, так как оно позволяет управлять доступом ко многим таким особенностям, к которым вы бы не хотели предоставить не- посредственный доступ для других пользователей. К сожалению, в эти программы может кто-нибудь проникнуть, чтобы использовать их времен- ный корневой статус для вредительства, которое мы уже описывали. Та- ких файлов имеется конечное число, и все они могут быть проверены. Рассматриваемый далее командный файл chkset автоматизирует для вас процесс проверки. Тем не менее, знание того, какие файлы МОГЛИ быть подвергнуты вмешательству, еще ничего не говорит о том, в какие файлы ДЕЙСТВИТЕЛЬНО произошло вторжение и как. Тяжелее всего обнаружить за- латанные системные файлы. Некоторыми из часто латаемых файлов являют- ся login, su, passwd, ps, crypt и mv. Бывает, что изощренный нарушитель скрывает даты модификации фай- ла, чтобы никто не смог его обнаружить по этому признаку. Единствен- ный способ зафиксировать такое вмешательство - иметь КОНТРОЛЬНУЮ СУМ- МУ, т.е. запись с суммой (количеством байтов) всех важных файлов и хранить ее в отдельном месте или в закодированном виде. Путем перио- дической сверки старых сумм с новыми, можно обнаружить измененные файлы. Еще одна вещь, за которой должен следить администратор, это "скрытые файлы". Скрытые файлы являются частью системы и имеют опре- деленный смысл: они предназначены для того, чтобы не загромождать распечатки каталогов. Для того чтобы скрыть файл, нужно сделать пер- вым символом имени файла точку (.). При использовании команды ls вы должны указать опцию -a, если вы хотите увидеть файлы, начинающиеся с точки. Обнаружение запрещенных файлов может быть затруднено, если файл зарыт на три-четыре уровня каталога вниз и назван незаметным именем. Решение заключается в том, чтобы всегда применять опцию -a команды ls, если вы сталкиваетесь с проблемами. Некоторые команды по умолчанию печатают файлы, начинающиеся с точки. Ncheck(1M) печатает все файлы, имеющие взведенный бит разрешения установки пользователь- ского идентификатора. Если файл назван странным образом, его сразу же видно. Одним из моих любимых является файл "...". Он выглядит нес- колько странно, но это правильное имя файла. Вы даже можете завести имя файла, образованное 14 точками - такова максимальная длина имени файла. КОМАНДЫ su Последний вопрос, за которым нужно следить,- запрещенные команды su. Su - это такое средство, которое позволяет вам ПОДСТАВИТЬ другой пользовательский идентификатор вместо вашего собственного. Если кто-то знает корневой пароль, он может войти в систему с любого тер- минала и применить команду su с корневым паролем. Однако, это, веро- ятно, тот случай, когда нарушители потратят больше всего времени, пы- таясь чего-либо добиться. Дело в том, что все транзакции su записываются в протокольный файл под названием sulog. Правда, к сожа- лению, если уж нарушитель стал суперпользователем, то ему ничто не мешает модифицировать протокольный файл с целью удаления компромети- рующих записей. К тому же если редактор vi вызван без имени файла, то никто не может увидеть, какой файл редактируется в то время, когда в системе происходит вредительство. Но бдительный системный администратор может бороться с этим при помощи команды ps. Она печатает строку о команде su точно так же, как она делает это для всех остальных процессов, поэтому можно сразу же заметить, что кто-то превратился в суперпользователя командой su. На- рушителя выдает то, что родительский процесс имеет регистрационное имя, а владельцем su является суперпользователь. Наконец, все равно же нужен корневой пароль. А если кто-то уже знает корневой пароль, то зачем ему связываться с командой su? Применять su было бы резонно только в том случае, если бы залатать команду su так, чтобы она не записывала транзакцию в протокол и изменяла строку, которую печатает ps. Мы еще не знаем, чтобы кто-нибудь добился такого эффекта. СОХРАНЕНИЕ КОНФИДЕНЦИАЛЬНОСТИ ДАННЫХ Даже если допустить, что секретность обеспечена, бывают случаи, когда администратору нужно защитить важные файлы от любопытных глаз. В системе UNIX это можно сделать с помощью специальных атрибутов за- щиты файла, специальных групповых прав доступа, шифровки или даже размещения этих данных на диске, который монтируется только в случае необходимости. Однако, такие данные не должны оставаться физически присутствующими в системе, если они не монтированы, потому что нару- шитель может их смонтировать и получить к ним доступ. Командный файл mntlook, рассмотренный ранее, умеет просматривать все устройства и находить такие доступные, но немонтированные файловые системы. Необходимо соблюдать такое правило: "Если вы не хотите, чтобы кто-нибудь видел этот файл, не держите его на виду". И не думайте, что вы так хорошо его спрятали, что никто не сможет его найти. Если люди имеют суперпользовательский доступ в вашу систему, они могут за считанные минуты получить распечатку каждого файла этой системы. За- тем, когда вы не видите, они могут при помощи uucp передать интерес- ный файл в другую систему для последующего изучения, скопировать его на гибкий диск или даже отпечатать. Помните, что если в вашу систему проник несанкционированный пользователь, НИКАКОЙ БЕЗОПАСНОСТИ БОЛЬШЕ НЕТ! КОНТРОЛЬ ЗА ИСПОЛЬЗОВАНИЕМ МОДЕМА Модемы являются одной из крупных пробоин в защите системы. Если только у вас нет специальной аппаратуры для предварительной фильтра- ции обращений в систему UNIX, то она всегда уязвима посредством мо- демных портов. Большие вычислительные системы могут иметь произвольное число модемов, как принимающих, так и передающих. Вам может показаться, что поскольку команда login имеет дополнительный пароль для линий с набо- ром номера, то все секретно, но это не так. Имеются программы, кото- рые могут пробовать много комбинаций вероятных регистрационных имен и паролей, и в случае подходящей комбинации команда login может впус- тить нарушителя в систему! Обращение вовне, в другие системы через модемы - отдельная исто- рия. Обычно тот, кто правильно зарегистрировался в системе, хочет обращаться к другим системам. Но что, если на вашей стороне имеются улавливающие регистрационные имена типа class, education, test и т.д.? Кто-то может войти в систему под видом одного из таких пользо- вателей и использовать модем безо всякого риска быть схваченным за руку. Единственный способ поймать таких нарушителей - по номеру тер- минальной линии, если у вас имеются специально выделенные линии. Что произошло бы, если бы тот, кто вошел в вашу систему через модем при помощи одного из перечисленных регистрационных имен, обра- тился бы потом вовне, к какой-нибудь "дальней земле"? Тогда не было бы никакой возможности уследить за обратным вызовом определенного пользователя. ПРЕДОТВРАЩЕНИЕ ЗАПРЕЩЕННЫХ ПЕРЕСЫЛОК ФАЙЛОВ Запрещенные пересылки файлов имеют отношение почти исключительно к средствам uucp. В системе Berkeley (BSD 4.1 и старше) сетевые ко- манды также имеют аналогичные проблемы. Вот пример: если кто-то за- пускает в системе Berkeley командный файл для "взлома двери", то ко- манда удаленной регистрации в системе (rlogin) регистрирует нарушителя на другой машине в качестве суперпользователя и никогда не спрашивает корневой пароль. Разве это не очевидная пробоина в систе- ме? Несанкционированный пользователь может также применить удаленное копирование (rcp), чтобы скопировать программу "взлома двери" во все системы. Самое главное следить за протокольными файлами. Но опять же, что если нарушитель удаляет из протокольных файлов все записи, связанные с заданием вопросов? У вас нет способа узнать о том, что это произош- ло. Еще нужно следить за таким поведением нарушителей, когда они де- лают вызов и выдают себя за корректную удаленную систему. Они могут добиться этого, изменив узловое имя своей системы таким образом, что- бы оно соответствовало одному их ваших разрешенных "корреспондентов". Изощренного нарушителя очень трудно поймать, но мы предлагаем некото- рые идеи, которые должны вам в этом помочь. СВЕДЕНИЕ К МИНИМУМУ ВОЗМОЖНОСТЕЙ ВЗЛОМА Это то, чем администраторы часто пренебрегают. Совет номер один - НИКОГДА не оставлять без присмотра терминал, зарегистрированный как суперпользовательский. Бросить без присмотра терминал с корневым дос- тупом - все равно, что оставить тысячу ключей от сейфа компании на вашем столе. Все несанкционированные пользователи могут воспользо- ваться этим, подготовив командный файл "взлома двери", ожидающий та- кого момента. Как только они получают в свои руки ваш терминал, всего лишь одна команда предоставляет им безграничные суперпользовательские возможности. С этого момента система перестает быть защищенной. Системные администраторы должны проверять свои системы и смот- реть на них с точки зрения нарушителя. Есть ли хоть когда-нибудь мо- мент, в который система уязвима? Что может произойти среди ночи, ког- да работают программы резервного копирования? Может ли кто-нибудь завладеть консольным терминалом? Не сможет ли навредить тот, кто при- ходит к вам помогать? Если вы на секундочку вышли, не сможет ли кто-то применить команду chmod, а потом заполнить экран чем-нибудь другим, чтобы вы не узнали, что это было сделано? Вот те опасности, о которых вам нужно помнить. ТИПИЧНЫЕ ПРОБЛЕМЫ БЕЗОПАСНОСТИ Рассмотрев в общих чертах обязанности системных администраторов и, в частности, основные вопросы системной безопасности, мы готовы теперь к более детальному изучению того, как могут произойти наруше- ния защиты. Каждый метод вмешательства в систему имеет свои преиму- щества и недостатки с точки зрения нарушителя и оставляет возможность борьбы с ним. Будучи осведомленным об этих характеристиках, админист- ратор получает хороший шанс обнаружить пробои в защите и выявить по- тенциальных нарушителей. ПОТАЙНЫЕ ДВЕРИ Мы уже отмечали, что люди, которые могут получить суперпользова- тельский доступ в систему хотя бы на короткое время, могут написать программы, предоставляющие им постоянный суперпользовательский дос- туп. Напомним, что тот, кто хочет прорвать защиту системы UNIX, пер- вым делом пытается найти способ стать суперпользователем. Как мы уже обсуждали, нарушение физической защиты или плохо оберегаемый корневой пароль могут дать нарушителю возможность запустить процесс как супер- пользовательский, что предоставляет доступ к файлам (например, стан- дартным исполняемым модулям системы UNIX), которые не может изменить обычный пользователь. В результате нарушитель получает для себя "по- тайную дверь". Ключевым вопросом является способ хранения в системе UNIX указа- ний о владельце и привилегиях, связанных с файлом. Помимо хорошо из- вестных прав доступа для владельца, группы и прочих пользователей (эти права устанавливаются командой chmod), имеется два более старших бита, называемых setuid (установка пользовательского идентификатора) и setgid (установка группового идентификатора). Как правило, процесс, запущенный данным пользователем, имеет только те привилегии на доступ, которые принадлежат этому пользовате- лю. Однако, многие системные команды должны иметь доступ к таким фай- лам, к которым мы бы не хотели разрешать доступ пользователя, за иск- лючением очень ограниченного набора ситуаций. Ярким примером является команда passwd, позволяющая пользователю сменить свой пароль. Очевид- но, что этой команде необходим доступ на запись в файл /etc/passwd, а такой доступ имеет обычно только суперпользователь. Проблему решает исполняемый файл команды passwd, в котором бит setuid установлен на владельца файла, а владельцем файлов, соответс- твующих обычным системным командам, является суперпользователь (поль- зовательский идентификатор 0). Это означает, что ВО ВРЕМЯ РАБОТЫ ПРО- ЦЕССА, соответствующего данной команде, пользователь имеет корневые привилегии! Когда команда завершается, прекращается и корневой доступ ... если только в данную команду не было какого-то вмешательства или если нарушитель не установил особую программу setuid. В этих случаях остается только войти в потайную дверь. Потайная дверь - это чаще всего файл, владельцем которого явля- ется суперпользователь, но который подвергнут вмешательству несанкци- онированного пользователя, завладевшего каким-то образом правом дос- тупа на запись в этот файл, обычно путем временного суперпользовательского доступа. Важно понимать, что потайная дверь - это просто еще один процесс, порожденный из обычного пользовательско- го интерпретатора shell, но с одной существенной особенностью: у него другой номер пользовательского идентификатора - как правило, 0, т.е. идентификатор суперпользователя. Поскольку пользовательский идентифи- катор хранится в самом процессе, он может быть подвергнут вмешатель- ству. Фактическое проникновение в систему с обретением возможностей суперпользователя происходит тогда, когда работает "дверная" програм- ма. Здесь используется волшебство бита setuid. Когда этот бит взве- ден, программа устанавливает (или изменяет) пользовательский иденти- фикатор процесса на пользовательский идентификатор владельца данного файла (который оказывается суперпользовательским). Пока этот пользо- вательский идентификатор временно является суперпользовательским, программа превращается в shell-интерпретатор (обычно путем выполнения системного вызова exec). Такой shell находится по другую сторону две- ри, в царстве суперпользователя, со всеми принадлежащими ему привиле- гиями. Как мы уже отмечали, обсуждая команды su, более изощренные нару- шители могут различными способами маскировать свое прониконвение в систему. Один из способ маскировки - иметь "дверную" программу, кото- рая ничего не делает, если только она не вызвана с какой-нибудь неза- метной опцией, например -z. Скорее всего, программа потайной двери не выдает сколько-нибудь полезного синтаксического сообщения, если ее вызвать без правильной опции. Еще одна хитрость заключается в том, что программа потайной две- ри может изменить свою командную строку (которую можно отобразить при помощи команды "ps -ef", выдающей полное состояние процесса) на какую -нибудь безобидную, запускаемую обычно суперпользователем (например, getty). Опытный нарушитель вряд ли оставит исходный текст программы по- тайной двери в системе, поэтому администратор вынужден разглядывать только исполняемый модуль. Для реассемблирования объектного кода мож- но применить отладчик (adb), но если только вы не имеете безумно близкого знакомства с внутренностями системы UNIX, вам будет весьма трудно представить себе, что происходит. Изощренные программы потай- ной двери избегают также присутствия легко узнаваемых строк в испол- няемых модулях. Вы можете, однако, применить команду strings (если она есть в вашей системе) для поиска символьных строк, которые там могли бы быть. ПРОТОКОЛЬНЫЕ ФАЙЛЫ Одна из простейших ловушек для того, кто пытается добыть права суперпользователя - создавать запись, помещаемую в протокольный файл. При этом администраторам нужно следить за протокольными файлами, не появляются ли там записи, которые могут быть признаком злодейства. Ниже мы покажем вам инструментальное средство, которое автоматически следит за одним из таких протокольных файлов - файлом sulog, содержа- щим транзакции "замененного пользователя". Другой протокольный файл, часто нуждающийся в проверке, это протокол программы uucp, потому что эта программа может быть использована для несанкционированных пересы- лок файлов. Многие нарушители пытаются проверить протокольные файлы и удалить компрометирующие записи, сгенерированные при их вмешательст- ве. В арсенале администратора есть средства борьбы с этим. Они не на 100 процентов эффективны, но отлавливают некоторых нарушителей и, ус- ложняя им жизнь, могут отбить охоту вторгаться в систему. В дополнение к обычным протокольным файлам, поддерживаемым сис- темой UNIX, некоторые администраторы заводят свои собственные прото- кольные файлы, а затем подправляют ключевые команды так, чтобы они помещали данные в эти новые регистрационные файлы в процессе своей работы. Это может помочь обезвредить неосторожных лазутчиков. Один знакомый администратор сделал протокольный файл для команды cu и наз- вал его /tmp/.../.culog. Довольно умный тайный фокус, но в /usr/lib/crontab у него была запись для периодической печати этого файла. Это его выдавало: нужно было маскироваться получше. Заметим также, что ваши "скрытые" имена протокольных файлов могут быть извле- чены путем просмотра исполняемого образа команды с помощью утилиты strings. Если у вас есть пользователь, от которого вы ожидаете чего-ни- будь запрещенного, вы должны уметь установить специальную систему ре- гистрации, которая запускала бы более совершенный механизм, когда та- кой пользователь работает в системе. Программу watch из главы 6 можно модифицировать так, чтобы она вызывала специальную протоколирующую программу, когда в систему входит пользователь из известного списка. Протоколирующая программа могла бы повторять команды ps (process status, состояние процесса) и/или делать "моментальные снимки" обыч- ных регистрационных файлов (особенно учетных файлов) и направлять ре- зультаты в припрятанный протокольный файл. Идея состоит в том, что опасные процессы можно было бы обнаружить до того, как нарушитель по- лучает возможность войти в протокольные файлы и изменить их. (Видимо, вам нужно избегать применения команды at в такой программе, а перио- дически пользоваться вместо нее командой sleep. В противном случае, нарушитель может распознать ваши мероприятия по записи файла crontab.) Как только вы имеете результат о сеансе работы опасного пользователя, вы можете запустить grep для поиска интересующих вас имен или написать инструментальное средство, котор