Максимальная Безопасность:

Руководство Хакера по Защите Вашего Internet Сайта и Сети

Предыдущая главаСледующая главаСодержание

17

UNIX: The Big Kahuna

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

Люди UNIX отдельное поколение. Некоторые могут знать брандмауэры, некоторые могут знать сканеры, некоторые могут уметь эксплуатировать сценарии, и т.д. Однако они имеют одну общую черту: Они знают свою операционную систему чрезвычайно хорошо. Средний администратор UNIX системы, вероятно, писал собственные драйверы принтера и не раз. Он также вероятно брал исходный код различных готовых утилит и переделывал его по своему конкретному вкусу. Так что эта глава, чтобы быть интересной для всех, должна быть заполнена технической информацией практического значения.

Наоборот, есть много читателей, обыскивающих эти страницы, чтобы узнать об основах безопасности UNIX системы. Возможно они недавно установили Linux или FreeBSD, потому что это был недорогой выбор для быстрого решения Web сервера. Возможно они имеют машину UNIX, работающую как брандмауэр в их офисах, поддерживаемую некоторым внешним техником, и они хотят знать то, что она фактически делает. Или возможно этот класс читателей включает журналистов, которые понятия не имеют о UNIX, и их редакторы требуют, чтобы они немного поучились.

Я рассмотрел все эти вещи до написания даже единственного параграфа. Каков был конечный результат? Длинная глава. Люди UNIX могут пробегать через каждый раздел. (Здесь и там есть лакомые кусочки, где появляется важная информация, так что не упустите их.) Остальная часть людей может читать главу как полный блок и изучать следующее:

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

Платформа UNIX в Целом

Платформа UNIX развилась за эти годы. Сегодня она может быть определена как 32- (или 64-) битная многозадачная, многопользовательская, сетевая операционная система. Она имеет продвинутые возможности безопасности, включая контролируемое управление доступом, шифрование и аутентификацию.

Может ли UNIX Быть Безопасной?

UNIX может быть безопасна. Однако она не безопасна в ее родном состоянии (то есть коробочном). Коробочные слабости существуют для каждой разновидности UNIX, хотя некоторые дистрибутивы более небезопасны, чем другие. Например, некоторые версии IRIX (SGI) или наиболее ранние версии Linux имеют дыры Класса A или B. (Эти дыры позволяют посторонним получать неавторизованный доступ.) Эти дыры не проблема терминала (это не каламбур*1); они просто должны быть закрыты при первой инсталляции. Когда это сделано, эти версии UNIX не отличаются от большинства других версий небезопасной UNIX.

Что Является "Безопасной" UNIX?

Что является безопасной UNIX (или как ее иногда называют, доверенной UNIX)? Безопасная UNIX это любая UNIX платформа, которая определена Агентством Национальной Безопасности (NSA - National Security Agency) имеющей превосходное управление безопасностью. Эти версии должны быть в Списке Оцененных Продуктов NSA (EPL - Evaluated Product List). Продукты в этом списке были строго протестированы при различных условиях и рассматриваются безопасными для использования, включающего полу чувствительные данные.

Этот процесс оценки находится под управлением Программы Оценки Доверенных Продуктов, которая проводится от имени Национального Центра Компьютерной Безопасности, организаций, которые являются элементами Агентства Национальной Безопасности. Это люди, которые определяют какие продукты являются "безопасными" для использования в безопасных и полу безопасных средах.

Продукты оцениваются согласно предопределенному индексу. Этот индекс имеет различные уровни "гарантий", или классов безопасности. Как описано в TPEP FAQ:

Класс это определенная коллекция требований в Критериях Оценки Доверенных Компьютерных Систем (TCSEC - Trusted Computer System Evaluation Criteria), которым соответствует оцененная система. В TCSEC есть семь классов: A1, B3, B2, B1, C2, C1 и D, в порядке уменьшения возможностей и гарантий. Таким образом система, оцененная классом B3, имеет более расширенные возможности безопасности и/или более высокую уверенность, что возможности безопасности работают как предполагалось, чем система, оцененная классом B1. Требования для более высокого класса всегда надмножество более низкого класса. Таким образом система B2 выполняет любое функциональное требование C2 и имеет более высокий уровень гарантий.
Ссылка: "TPEP FAQ: What Is a Class?" ("TPEP FAQ: Что такое Класс?") может быть найден в онлайне на
http://www.radium.ncsc.mil/tpep/process/faq-sect3.html#Q4.

Два продукта UNIX, которые находятся в начале списка (уровни B3 и B2, соответственно) идентифицированы в Таблице 17.1. Согласно Агентству Национальной Безопасности это наиболее безопасные операционные системы на планете.

Таблица 17.1. Доверенные, безопасные продукты UNIX.

Операционная Система Поставщик Класс
XTS-300 STOP 4.1a* Wang Federal, Inc. B3
Trusted XENIX 4.0* Trusted Information Systems, Inc. B2

*Эти операционные системы имеют более ранние версии, которые все были определены той же самой категорией. Я перечислил только самые последние версии этих продуктов.

Чтобы исследовать более ранние версии (и их рейтинги), обратитесь к
http://www.radium.ncsc.mil/tpep/epl/epl-by-class.html.
XTS-300/STOP 4.1a Wang Federal не только операционная система, но и полный пакет. Он состоит из и аппаратного обеспечения (Intel 80486 PC/AT, системная шина EISA) и программного обеспечения (операционная система STOP 4.1a). Он включает UNIX-подобный интерфейс на более низких уровнях системы. На более высоких уровнях он использует иерархическую файловую систему. Эта операционная система имеет предельное DAC (управление доступом к данным) и подходит для ответственной работы. STOP 4.1a имеет самую большую оценку из всех операционных систем. Как сообщено EPL:

Кроме минимальных требований для B3 системы, XTS-300 обеспечивает принудительную политику целостности, дополнительную политику подтипов, и знакомую, UNIX-подобную среду для одноуровневых приложений. Целостность может использоваться, среди других вещей, для защиты от вирусов. UNIX-подобная среда поддерживает двоичную совместимость и выполняет многие программы, импортированные из других систем без перекомпиляции.
Ссылка: Вы можете найти этот отчет EPL в онлайне на
http://www.radium.ncsc.mil/tpep/epl/epl-by-class.html.

Когда ни будь ночью, когда Вы немного платите за время, посетите сайт Wang Federal (http://www.wangfed.com/). Технический Обзор системы XTS-300 ошеломит Вас. На каждом уровне системы и для каждой базы данных, приложения, пользователя, терминала и процесса, имеется уровень безопасности. Она работает используя конструкции, упоминаемые как "кольца изоляции". Каждое кольцо исключительно. Чтобы дать Вам идею относительно того, как невероятно плотна эта система безопасности, рассмотрите это: Кольцо 0, наибольший уровень безопасности, полностью недостижимо пользователями. Именно в пределах этого кольца постоянно находятся драйверы устройств Ввода/Вывода. Поэтому, никто и никогда не может получить неавторизованный доступ к драйверам устройств. Даже процессам ограниченным кольцевыми привилегиями позволяется взаимодействовать только с теми процессами, которые имеют те же самые или меньшие кольцевые привилегии. Невероятно. Но это еще не все. Если терминал связан с процессом, который имеет очень низкий уровень кольцевых привилегий, этот терминал не может одновременно подключаться к другому процессу или терминалу, поддерживающих более высокие привилегии. Другими словами, чтобы соединиться с процессом или терминалом с более высокими привилегиями, Вы должны сначала "отделить" ниже привилегированный процесс. Это истинная безопасность (особенно, потому что эти соглашения осуществляются непосредственно в системе).

Ссылка: Wang Federal ведущий поставщик технологии TEMPEST, которая предназначена для поражения перехвата и анализа электронных излучений, исходящих от вашего компьютера. Эти электронные сигналы могут "просачиваться" и быть перехвачены (даже за несколько сотен ярдов). Технология TEMPEST может предотвратить такой перехват. Это предотвращение обычно включает упаковывание аппаратного обеспечения в плотную, металлическую конструкцию, за которую радиация и излучения не могут выходить. Чтобы увидеть фотографию такого компьютера, посетите
http://ww.wangfed.com/products/infosec/pictures/tw3.gif.
Он выглядит скорее как сейф, чем компьютерная система.

Интересная мелочь: Если Вы ищете дыры в любом из продуктов Wang Federal, то будете искать очень, очень долго. Однако в одном неясном выпуске STOP (4.0.3), ошибка существовала. Очень немного информации доступно по этой ошибке, но 23 июня, 1995, относительно этого была выпущена консультация Военной Сети Передачи Данных (DDN - Defense Data Network). Проверьте эту консультацию сами. Она довольно загадочна и проясняет немного относительно уязвимости, но все равно интересна.

Ссылка: Вы можете найти консультацию DDN относительно STOP в онлайне на
ftp://nic.ddn.mil/scc/sec-9529.txt.

Следующий продукт это Trusted XENIX, операционная система, изготовленная Trusted Information Systems, Inc. Вы можете знать это название, потому что эта компания создает брандмауэры (типа известного Firewall Tool Kit и утилиты с названием Gauntlet, которая является огромным пакетом брандмауэром). TIS разработала целую линию не только продуктов безопасности, но и политик и теорий. TIS находится в бизнесе безопасности уже довольно долго.

Ссылка: Пожалуйста найдите время, чтобы проверить TIS на http://www.tis.com/ или исследовать продукты на
http://www.tis.com/docs/products/index.html.

Trusted XENIX это очень продвинутая в безопасности версия UNIX (и имеет небольшое сходство с продуктом Microsoft XENIX). Безопасность этого продукта основана на модели Bell и LaPadula.

Многие пользователи могут задаться вопросом, что такое модель Bell и LaPadula. Это модель безопасности, используемая военными организациями Соединенных Штатов. Она описана в Критериях Оценки Доверенных Компьютерных Систем Министерства Обороны (также известна как Оранжевая Книга, из ряда "Радуга Книг") как "... абстрактная формальная обработка политики безопасности DoD (Department of Defense - Министерства Обороны) ..."

Как сообщено в Оранжевой Книге:

Using mathematics and set theory, the model precisely defines the notion of secure state, fundamental modes of access, and the rules for granting subjects specific modes of access to objects. Finally, a theorem is proven to demonstrate that the rules are security-preserving operations, so that the application of any sequence of the rules to a system that is in a secure state will result in the system entering a new state that is also secure. This theorem is known as the Basic Security Theorem.
ПРИМЕЧАНИЕ: Найдите Оранжевую Книгу в онлайне на
http://www.v-one.com/newpages/obook.html.

Это звучит сложно, но на самом деле все проще. Модель предписывает ряд "правил" поведения. Эти правила поведения могут применяться и к людям (как при посылке военных супер секретов и секретных сообщений) или они могут относиться к уровням доступа, позволенным в данной системе. Если Вы глубоко заинтересованы изучением модели безопасности Bell и LaPadula, то должны приобрести Оранжевую Книгу. Кроме того, есть превосходный документ, который не только поможет Вам понять основы этой модели безопасности, но также ее слабости или причуды. Этот документ озаглавлен "A Security Model for Military Message Systems" ("Модель Безопасности для Военных Систем Обмена Сообщениями"). Авторы Carl Landwher, Constance L. Heitmeyer и John McLean. Документ предлагает некоторые новые концепции в отношении таких систем и противопоставляет эти новые подходы модели безопасности Bell и LaPadula. Этот документ уменьшает сложность предмета, позволяя пользователю легко понять концепции.

Ссылка: "A Security Model for Military Message Systems" может быть найдена в онлайне на
http://www.itd.nrl.navy.mil/ITD/5540/publications/CHACS/Before1990/1984landwehr-tocs.ps.

Другой превосходный документ "On Access Checking in Capability-Based Systems" ("Проверка Доступа в Мандатных Системах") (Richard Y. Kain и C. E. Landwehr) демонстрирует, как некоторые условия и среды не могут соответствовать модели безопасности Bell и LaPadula. Обсуждаемая информация может заполнить пробелы в ваших знаниях этих типов моделей безопасности.

Ссылка: Документ Kain и Landwehr, "On Access Checking in Capability-Based Systems", может быть найден в онлайне на
http://www.itd.nrl.navy.mil/ITD/5540/publications/CHACS/Before1990/1987landwehr-tse.ps.

Trusted XENIX имеет очень детализированное управление доступом, возможности контроля и списки управления доступом. Кроме того, система распознает четыре уровня безопасности пользователей (или привилегий пользователей):

Только один из них (ревизор) может изменять log-файлы. Это серьезная безопасность в работе. На таком уровне безопасности систем фокус находится на том кто, а не что, использует систему. Другими словами, операционные системы подобные этой не доверяют пользователям. Поэтому, конструкция системы полагается на строгую политику безопасного доступа, установленную для людей людьми же. Единственный способ взломать такую систему состоит в том, если кто-то внутри "не чист". Каждый человек занимающийся обслуживанием системы отделен от остальных. (Например, человек, который занимается инсталляцией, имеет свою собственную учетную запись, и эта учетная запись [Доверенный Системный Программист] может работать только в однопользовательском режиме.) Проект, поэтому, обеспечивает сверхвысокий уровень ответственности. Каждый так называемый доверенный пользователь ответствен за отдельную часть системной безопасности. Для того чтобы системная безопасность была полностью скомпрометирована, эти личности должны действовать в сговоре (что просто невероятно).

Также существуют версии безопасной UNIX, которые занимают более низкий уровень в EPL. Это чрезвычайно безопасные системы и часто имеют место в реальной жизни. XTS STOP и TIS Trusted XENIX представляют предельные меры безопасности, что не требуется средней организации или бизнесу. Такие системы создаются для супер параноиков. B1 систем много и они весьма безопасны. Вот некоторые из поставщиков, которые обеспечивают продукты B1:

ПРИМЕЧАНИЕ: Снова, я перечислил только самые последние версии этих продуктов. Во многих случаях более ранние версии также совместимы с B1. Пожалуйста, проверьте EPL для особенностей более ранних версий.

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

Мы собираемся начать с одной машины и затем выйти за нее. (Не очень новая идея, но она, по крайней мере, добавит некоторый порядок этой главе.)

Начало Начал

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

Безопасность Консоли

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

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

СОВЕТ: Немедленно после инсталляции установите корневой пароль. Многие дистрибутивы подобные SunOS или Solaris от Sun, запросят, чтобы Вы сделали это. Это обычно последняя опция, представленная до перезагрузки (SunOS) или загрузки (Solaris). Однако многие дистрибутивы не делают этого до первой загрузки. Linux Slackware один такой дистрибутив. AIX (AIX 4. x в частности, который загружается непосредственно в Korn оболочку) другой. Если Вы установили такую систему, установите корневой пароль немедленно после регистрации в ней.

Затем, есть несколько вещей, которые Вы должны проверить. Те, кто имеют физическую близость, но не имеют привилегий, все еще могут скомпрометировать вашу безопасность. После установки корневого пароля первый вопрос, который Вы должны задать себе, поддерживает ли ваша система однопользовательский режим. Если да, можете ли Вы отключить его или ограничить его использование? Многие системы поддерживают однопользовательский режим. Например, некоторые DECstations (3100, в особенности) позволяют Вам определять опцию загрузки:

Когда рабочая станция DEC запущена впервые, ее консольная система работает в привилегированном командном режиме. Если Вы ничего не сделаете, чтобы изменить привилегированный режим, не будет никаких ограничений консольных команд. Любой с физическим доступом к консоли может активизировать любую консольную команду, наиболее уязвимую интерактивной загрузке.
Ссылка: Предыдущий параграф это выдержка из CIAC-2303, The Console Password for DEC Workstations (Консольный Пароль для Рабочих Станций DEC) от Allan L. Van Lehn. Этот превосходный документ может быть найден в онлайне на
http://ciac.llnl.gov/ciac/documents/.

Интерактивная загрузка введет их в однопользовательский режим, и эта дыра должна быть закрыта немедленно после инсталляции. На рабочей станции DEC Вы можете установить консольный пароль.

Где Расположить Машину?

Затем, обратите внимание, что машина безопасна на столько, на сколько безопасно ее местоположение. Конечно, Вы не разместили бы машину с чувствительной информацией в физическом местоположении, где злонамеренные пользователи могли бы иметь неограниченный доступ к ней. "Неограниченный доступ" в этом контексте означает доступ, когда пользователи могут потенциально иметь время, без опасения быть обнаруженными, чтобы удалить покрытие или иначе вмешаться в аппаратное обеспечение. Такое вмешательство может привести к компрометации.

СОВЕТ: Некоторые машины имеют физические слабости, которые также свойственны платформе PC. На некоторых рабочих станциях тривиально отключить пароль ППЗУ. Например, удаление чипа nvram на рабочих станциях Indigo уничтожит пароль ППЗУ.

Как отмечено в RFC 1244:

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

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

Защита Ваших Инсталляционных Носителей

Ваши инсталляционные носители должны храниться в безопасном месте. Помните, что инсталляционные носители могут использоваться, чтобы скомпрометировать систему. Например, наши более подготовленные читатели могут помнить, что это может быть сделано с некоторыми версиями AT&T UNIX, особенно SVR3 и V/386. Эта методика включает вставку загрузочной дискеты, загрузки с нее (в противоположность жесткому диску), и выбору опции "magic mode" ("волшебный режим"). Это предоставляет средства для входа в оболочку.

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

Инсталляции, которые происходят исключительно через CD-ROM, менее вероятно предложат злонамеренному пользователю усиленный доступ. Однако примите к сведению, что эти типы инсталляций также представляют риск. Вы должны думать так же, как думает злонамеренный пользователь. Если ваш SPARC находится на столе с доступным инсталляционным носителем, Вам лучше берете предпринять некоторые меры предосторожности. Иначе, дитя может подойти, остановить машину (L1 + A), загрузить инсталляционный носитель (с b sd(0,6,2)), и приступить к перезаписи всего диска. Злонамеренный пользователь может также выполнить эту операцию с почти любой системой (например, изменяя SCSI ID на приводе жесткого диска). AIX загрузится с CD-ROM, если найдет, что все другие диски неподходящи для загрузки.

Однако более часто системная безопасность нарушается с помощью загрузочной дискеты. Типичные примеры инсталляционных процедур, которые требуют диск, включают SolarisX86, некоторые версии AT&T UNIX, некоторые версии SCO, и почти все дистрибутивы Linux. Если Вы имеете такую систему, защитите эти диски. (Правда злонамеренный пользователь может приобрести образы дисков в Internet или в других источниках. Однако это не так удобно, как наличие диска, с готовностью доступного, в непосредственной близости к рабочей станции. Большинство таких нарушений являются преступлениями по возможности. Не предоставляйте эту возможность.)

Ссылка: Увлекательный подход к проблеме физической безопасности рабочих станций принят в документе Dr. J. Douglas Tygar и Bennet Yee, Школа Информатики Университета Carnegie Mellon. Этот документ, Dyad: A System for Using Physically Secure Coprocessors (Dyad: Система для Использования Физически Защищенных Сопроцессоров), может быть найден в онлайне на
http://www.cni.org/docs/ima.ip-workshop/www/Tygar.Yee.html.

Прежде, Чем Вы Установите Сетевую Машину

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

Если Вы выполняете UNIX, ваша машина является сетевой. Нет никаких различий в том, что у Вас нет "сети" (кроме Internet) связанной с ней. UNIX по умолчанию является сетевой операционной системой. То есть если Вы не отключите сетевые опции, эта машина будет поддерживать большинство протоколов, используемых в Internet. Если Вам дали такую машину, используемую прежде для графических проектов, Вы должны или получить техника, квалифицированного в безопасности, или изучать безопасность самостоятельно. Ко времени, когда машина будет подключена к Сети, она должна быть защищена. Как я объяснял ранее в этой книге, недостаток знания безопасности плохо отражается на машинах многих пользователей SGI. Оконные системы замечательны (и системы SGI истинно красивы для созерцания). Однако в основе таких машин лежит развивающаяся, сетевая UNIX.

Коробочные Умолчания

В почти каждой разновидности UNIX есть некоторые пароль или конфигурация по умолчанию, которые могут привести к компрометации корневого пользователя. Например, в начале этой книги, я обсуждал проблемы с некоторыми версиями IRIX. Я кратко перечислю их здесь.

Следующие учетные записи некоторых версий IRIX не требуют пароля для входа:

Ссылка: Чтобы провести обзор проблемы паролей по умолчанию более близко, обратитесь к компании Silicon Graphics, Консультации по Безопасности 19951002-01-I; Консультации CERT CA-95:15--SGI lp Уязвимость. 27 Ноября, 1995.
ftp://sgigate.sgi.com/Security/19951002-01-I или
ftp://info.cert.org/pub/cert_advisories/CA-95%3A15.SGI.lp.vul.

С такими проблемами нужно иметь дело немедленно после инсталляции. Если Вы не сознаете такие слабости, свяжитесь с вашим поставщиком или организациями по безопасности.

Перейдем к Делу: Безопасность Паролей

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

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

ПРИМЕЧАНИЕ: Затенение пароля, это когда файл /etc/passwd содержит только лексемы (или символы), которые служат как абстрактное представление для реального, зашифрованного пароля пользователя. Этот реальный пароль хранится в другом месте диске, в месте, недостижимом взломщиками.

Некоторые дистрибутивы не имеют затенения как заданная по умолчанию возможность. Я не предполагаю здесь, что Вы устанавливаете самую большую и самую плохую UNIX систему, в настоящее время доступную на рынке. Возможно Вы устанавливаете SunOS 4_1_3 на старом SPARC 1, или подобное устарелое аппаратное и программное обеспечение. (Или возможно Вы устанавливаете Slackware версию Linux, которая не поддерживает затенение в текущем дистрибутиве.)

В таком случае файл /etc/passwd будет по крайней мере видим пользователями. Правда, пароли находятся в зашифрованной форме, но как Вы узнали ранее, взлом их является тривиальной задачей. Если они могут быть просмотрены, они могут быть взломаны. (Что ни будь, что может быть просмотрено, может также быть вырезано и вставлено. Все, что требуется, это некоторый терминальный пакет, который может использоваться с Telnet к вашей машине. После этого файл /etc/passwd может быть напечатан на STDOUT, он может быть снят с экрана или иначе скопирован.) Эти первое, что необходимо исправить.

Пароли в их необработанной, зашифрованной форме не должны быть никем видны. Современная технология предоставляет Вам утилиты для сокрытия этих паролей, и не существует никакой земной причины, почему Вы не должны использовать их. Было время, однако, когда такое сокрытие не было доступно. В те давние дни иногда случались причудливые и фантастические вещи. Фактически, на заре компьютерной технологии безопасность была в значительной степени случайной ситуацией. Вот забавная история, пересказанная Robert Morris и Ken Thompson в их теперь классической статье Password Security: A Case History (Безопасность Паролей: История Случая):

Опыт с несколькими более ранними системами удаленного доступа показал, что оплошности происходят с пугающей частотой. Возможно наиболее незабываемый такой случай произошел в начале 60-ых, когда системный администратор CTSS системы в MIT редактировал файл паролей, а другой системный администратор редактировал ежедневное сообщение, которое печаталось на всех терминалах при входе в систему. Из-за конструкторской ошибки программного обеспечения временные файлы редактора этих двух пользователей были обменяны и таким образом, какое-то время, файл паролей печатался на каждом терминале при входе в систему.
Ссылка: Password Security: A Case History может быть найдена в онлайне на
http://www.alw.nih.gov/Security/FIRST/papers/password/pwstudy.ps.

Установка Затенения Паролей

Если ваша система поддерживает это, Вы нуждаетесь в затенении паролей. Если Вы используете Linux, то можете получить Shadow Suite на
ftp.cin.net/usr/ggallag/shadow/shadow-current.tar.gz.

Для других систем я предлагаю затеняющий пакет John F. Haugh II. Этот пакет обширен по функциональности. Например, мало того, что он обеспечивает основное затенение паролей, он также может использоваться для устаревания паролей. Он может даже ограничивать порт, с которого корневой пользователь может входить. Кроме того, он поддерживает 16-символьные пароли (в противоположность традиционным 8). Это существенно расширяет вашу безопасность паролей, вынуждая взломщиков потреблять значительные ресурсы для взлома более сложного пароля. Другие возможности этого дистрибутива включают следующее:

Ссылка: Shadow доступен на
ftp://ftp.std.com/src/freeunix/shadow.tar.Z.

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

Ссылка: Взломщик доступен на
ftp://coast.cs.purdue.edu/pub/tools/unix/crack/.

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

Ссылка: Два хороших начальных места для списков слов
http://sdg.ncsa.uiuc.edu/~mag/Misc/Wordlists.html и
ftp://coast.cs.purdue.edu/pub/dict/.

ПРЕДОСТЕРЕЖЕНИЕ: Если Вы храните взломщиков паролей на ваших локальных дисках, удостоверитесь, что они не доступны ни для кого, кроме Вас. То же самое истинно для списков слов или любой другой утилиты, которая могла бы очевидно использоваться против вашей системы (или что-нибудь еще, в этом отношении). Многие утилиты безопасности соответствуют этому описанию. Убедитесь, что защитили все утилиты безопасности, которые могут быть потенциально использованы взломщиком.

Установка Действенной Программы Проверки Паролей

И так перечислим, Вы к настоящему времени выполнили следующие операции:

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

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

Ведущая утилита для этого passwd+, написанная Matt Bishop. Эта утилита довольно широко использовалась, в значительной степени из-за ее высоко уровневых функциональных возможностей. Это превосходная утилита. Например, Вы можете установить сообщение об ошибках, которое будет получено, когда пользователь дает слабый пароль. Другими словами, перед пользователем не ставится загадочная подсказка "Ваш пароль является плохим", поскольку она не служит для объяснения пользователям что является слабым или сильным паролем. (Такие сообщения также вероятно раздражали бы пользователя. Пользователи имеют небольшую терпимость к программе, которая неоднократно выдает такое сообщение об ошибках, даже если ошибка заключается в пользователе, а не в программе.) Программа также обеспечивает следующее:

Ссылка: passwd+ от Matt Bishop доступна на
ftp://ftp.dartmouth.edu/pub/security/.

Чтобы узнать больше об этой программе (и теории и практике приложенной к ней Bishop'ом), Вы должны получить технический отчет A Proactive Password Checker (Действенная Программа Проверки Паролей), Технический Отчет Dartmouth PCS-TR90-152. Он не доступен в Сети от Dartmouth. Однако Вы можете запросить его твердую копию по почте от
http://www.cs.dartmouth.edu/cgi-bin/mail_tr.pl?tr=TR90-152.

Следующий Шаг: Исследование Служб

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

r Службы

Какие службы Вы должны поддерживать? Например, Вы собираетесь позволить использование r служб? Это, прежде всего rlogin и rsh. Эти службы известны по дырам в безопасности не только в отдаленном прошлом, но и в течение всей их истории. Например, в августе 1996, была выпущена консультация относительно дыры rlogin в некоторых дистрибутивах Linux. Дыра в безопасности имела Класс A и Класс B, позволяя и локальным и удаленным пользователям получать усиленный доступ:

Уязвимость существует в программе rlogin NetKitB-0.6. Эта уязвимость распространяется на несколько широко используемых дистрибутивов Linux, включая Red Hat Linux 2.0, 2.1 и производные системы, включая Caldera Network Desktop, Slackware 3.0 и другие. Эта уязвимость не ограничивается Linux или любыми другими свободными UNIX системами. И информация по этой уязвимости и методов ее эксплуатирования была сделана доступной в Internet Alan Cox, Marc Ewing (Red Hat), Ron Holt (Caldera, Inc.) и Adam J. Richter, Official Update of the Linux security FAQ (Официальная Модификация FAQ по безопасности Linux); Alexander O. Yuriev, Moderator, Списки Рассылки Linux Security (Безопасность Linux) и Linux Alert (Предупреждения Linux). (Лаборатории CIS, Университет Temple, Филадельфия, PA.)

Проблема не ограничена Linux. Многие бескомпромиссные пользователи UNIX "смотря сверху вниз" на Linux принимают позицию, что Linux не является "настоящей" операционной системой UNIX. Так всякий раз, когда в Linux неожиданно возникают дыры, бескомпромиссное сообщество принимает позицию "Я же Вам говорил". Этот взгляд несостоятелен. Многие дистрибутивы настоящей UNIX имели подобные ошибки. Рассмотрите следующую консультацию IBM (озаглавленную "Urgent - AIX Security Exposure" – "Срочно - Дефект Безопасности AIX"):

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

Эта дыра была пролемой rlogind. На затронутых версиях AIX любой удаленный пользователь мог выдать эту команду: 

rlogin AIX.target.com -l -froot

и немедленно получал корневой доступ к машине. Это, конечно, дыра Класса A. И AIX не единственный дистрибутив, который имел проблемы с r службами. Фактически, почти все дистрибутивы UNIX имели ту или иную броблему с этими службами. Я рекомендую, чтобы Вы закрыли их.

Но что, если Вы не можете сделать так? Что, если Вы должны предложить по крайней мере ограниченный доступ, используя r службы? Хорошо, благодаря Wietse Venema это не проблема. Venema создала коллекцию захаканых утилит, которые заменят эти демоны. Эти утилиты предлагают расширенные возможности безопасности и регистрации. Кроме того, Venema обеспечивает обширную историю их разработки.

Ссылка: Вы можете найти захаканые утилиты Venema на
ftp://ftp.win.tue.nl/pub/security/.

Ссылка: Опечатки, изменения, исправления, усовершенствования и история этих утилит расположены на
ftp://ftp.win.tue.nl/pub/security/logdaemon-5.6.README.

Также маловероятно, что Вы схватили утилиты на лету и не в состоянии прочитать файл README. Пожалуйста прислушайтесь по крайней мере к авторским предупреждениям Venema:

Многие программы в этом комплекте заменяют системные утилиты. Не заменяйте системные утилиты, если Вы не являетесь опытным системным программистом или системным администратором.
Ссылка: Файл README Venema может быть найден в онлайне на
ftp://ftp.win.tue.nl/pub/security/logdaemon-5.6.README.

СОВЕТ: Многие подобные утилиты заменяют системные демоны. Я рекомендую, чтобы перед использованием любой такой утилиты, Вы тщательно прочитали инсталляционные и readme примечания. Если Вы не сделаете так, то можете закончить с системой, которая не работает должным образом.

ПРЕДОСТЕРЕЖЕНИЕ: Venema сделала большой вклад Безопасность Internet и высоко уважается. Однако даже она способна к созданию незначительных ошибок. Обратите внимание, что версии logdaemon до 4.9 имеют испорченную реализацию S/Key, продукт Bellcore, используемый для аутентификации. Дыра не критическая (Класс A), но локальные пользователи могут получать неавторизованный доступ. Для дальнейших справок и ссылок на исправленные версии, смотрите CERT Vendor-Initiated Bulletin (Бюллетень CERT Инициированный Поставщиком) VB-95:04, который расположен на
http://www.beckman.uiuc.edu/groups/biss/VirtualLibrary/mail/cert/msg00012.html.

Есть также другие решения проблемы. Имеются пути, например, чтобы отключить r службы, но поддерживать другие формы удаленного входа в систему. Одно такое решение это Secure shell (SSH - Безопасная Оболочка). SSH доступна во многих местах в Internet. Я предпочитаю этот сайт:

http://escert.upc.es/others/ssh/ ..

SSH в настоящее время доступна для широкого диапазона платформ. Вот несколько:

Как я обсуждал предварительно, SSH обеспечивает сильную аутентификацию и шифрование удаленных сеансов. Это превосходная замена для rlogin и даже для Telnet. Telnet. Кроме того, SSH отражает многие обманные нападения через IP и DNS. Многие администраторы говорят, что, если Вы не поддерживаете r службы, Вы должны удалить файлы /etc/hosts.equiv и .rhosts. Обратите внимание, что клиент SSH поддерживает аутентификацию через .rhosts и /etc/hosts.equiv. Если Вы собираетесь использовать SSH, рекомендуется сохранить один или оба этих файлов. Перед фактической реализацией SSH на вашей системе было бы мудрым изучить RFC, связанный с этой проблемой. Он озаглавлен "The SSH (Secure Shell) Remote Login Protocol" ("Протокол Удаленного Входа в Систему SSH (Безопасная Оболочка)").

Ссылка: "The SSH (Secure Shell) Remote Login Protocol" от T. Ylonen (Технологический Университет Хельсинки) может быть найден в онлайне на
http://www.cs.hut.fi/ssh/RFC.

ПРЕДОСТЕРЕЖЕНИЕ: Файлы /etc/hosts.equiv и .rhosts должны проверяться. Любое изменения или отклонения в этих файлах одно из указаний возможной компрометации безопасности вашей системы. Кроме того, файл /etc/hosts.equiv должен быть исследован очень близко. Символы +, !, - и # не должны появляться в этом файле. Этот файл отличается по конструкции от других файлов, и эти символы могут разрешить удаленным личностам получить неограниченный доступ. (Смотрите RFC 91:12 и связанные RFC.)

Кроме того, Вы вероятно захотите предписать строгую политику относительно файлов .rhosts на вашей машине. То есть Вы должны строго запретить пользователям на вашей машине устанавливать файлы .rhosts в их собственные /home каталоги. Вы можете применить всю безопасность в мире для вашего персонального использования .rhosts и это не будет иметь значения, если пользователи не рассматривают дыру в вашей безопасности, как в своей собственной.

Утилиты Высматривания: Служба finger

Есть разногласия в отношении безопасности утилиты finger. Некоторые администраторы доказывают, что использование службы finger будет иметь почти незначительный эффект для безопасности. Их взгляд состоит в том, что в большой системе могут потребоваться века, чтобы взломщик сформировал надежную базу данных пользователей и процессов. Кроме того, обсуждается, что с введением динамически распределяемых IP адресов, эта информация может быть испорчена для целей взлома (например, приводится аргумент, что команда finger @target.host.com покажет только тех пользователей, которые в настоящее время зарегистрированы на машине. Это может быть истинно для многих дистрибутивов fingerd, но не для всех). Однако администраторы доказывают, что взломщики встретятся с большой повторяющейся и бесполезной информацией, делая попытку сформировать базу данных этим путем. Эти непредвиденные обстоятельства теоретически помешали бы взломщику, расстроив его запрос. Эта методика рассматривается как слишком проблемная. Возможно. Но как Вы скоро увидите, в действительности это не так. (Кроме того, для некоторых дистрибутивов, это даже не проблема.) Попробуйте выдать следующую команду против Ultrix fingerd: 

finger @@target.host.com

Распечатка, которую Вы получите в ответ, потрясет Вас. В некоторых версиях Ultrix fingerd эта команда выдаст список всех пользователей из файла passwd.

Я чувствую, что функциональные возможности удаленных finger запросов должны быть устранены в целом (или по крайней мере, ограничены с точки зрения вывода). Экспериментирование с finger запросами (против вашего сервера или чьего ни будь другого) покажет некоторые очень интересные вещи. Во-первых, знайте следующее: finger запрос любого символа, который мог бы появиться в структуре пути, покажет целые списки людей. Например, предположим, что Вы структурируете ваши каталоги для пользователей как /u1, /u2, /u3 и так далее. Если Вы сделаете так, попытайтесь выдать следующий finger запрос: 


finger 4@my.host.com

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

Однако, если Вы чувствуете потребность позволить службы finger, я предлагаю использовать некоторую "безопасную" форму finger, типа высоко настраиваемого fingerd, написанного Laurent Demailly. Одной из его основных возможностей является то, что он позволяет доступ к plan файлам через каталог chrooted. sfingerd (который почти всегда поступает с полным исходником) доступен на
ftp://hplyot.obspm.fr:/net/sfingerd-1.8.tar.gz.

Другие известные демоны finger, различающиеся своими возможностями ограничивать некоторое поведение, перечислены в Таблице 17.2.

Таблица 17.2. Альтернативные демоны finger.

Демон Расположение и Общие Характеристики
fingerd-1.0 ftp://kiwi.foobar.com/pub/fingerd.tar.gz.

Предлагает расширенную регистрацию и позволяет ограничения на отправление.
cfinger ftp://sunsite.unc.edu:/pub/Linux/system/network/finger/cfingerd-1.3.2.lsm.

Может использоваться, чтобы обеспечить выборочные службы finger, отвергая одного пользователя, но позволяя другому. Для finger запросов от уполномоченных пользователей могут быть выполнены сценарии.
rfingerd ftp.technet.sg:/pub/unix/bsdi/rfingerd.tgz.

Интересное завихрение: Perl демон. Позволяет условное выполнение и ограничения, например if {$finger_запрос_пользователя eq 'foo'} {выпонить_эту_операцию}. Прост в использовании, маленький, легкий. (Это Perl, в конце концов.)

Есть другие причины для отключения finger. Одна из них файл .plan. На машине ISP файл .plan имеет обычно небольшое значение и используется по его самому обычному назначению: обеспечивать небольшую дополнительную информацию в ответ на finger запрос. Однако в сетях, связанных с Internet, само собой разумеется (особенно в корпоративной атмосфере), что файл .plan может служить другим целям (например, сообщать о состоянии проектов). Этот тип информации может рассматриваться чувствительным.

Если Вы чувствуете потребность выполнять finger, ограничьте его использование людьми в пределах вашей сети. Или, если это не возможно, загрузите один из безопасных демонов finger и исследуйте его код и документацию. Только затем Вы должны сделать свой выбор.

ПРИМЕЧАНИЕ: Было сообщено в нескольких документах, включая Arts and Sciences UNIX System Administrator Guidelines (Рекомендации по Искусству и Наукам Администратора UNIX Системы) Университета Duke, что Вы не должны использовать GNU fingerd версии 1.37. Очевидно, в этой версии есть дыра, которая позволяет пользователям обращаться к привилегированным файлам.

Другие Удаленные Службы

Следующим шагом необходимо исследовать какие другие удаленные службы Вы предложите. Вот некоторые вопросы, которые Вы должны задать себе:

Telnet

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

ПРИМЕЧАНИЕ: Один хороший пример это Red Hat Linux 4.0. Проблема не серьезна, но Telnet в этом дистрибутиве может показать больше информации, чем Вы хотели. Предположим, что Вы отключили службы finger, r службы и команду EXPN в Sendmail. Предположим далее, что Вы однако позволяете сессии Telnet с недоверенных адресов. (Другими словами, Вы не выполняете программного обеспечения брандмауэра и не имеете никаких других средств исключения недоверенных, неизвестных, или подозрительных адресов.) С этой конфигурацией Вы чувствуете себя уверенным, что никто не может идентифицировать допустимые имена пользователей в вашей системе. Это в действительности так? Нет. Пакет Telnet в дистрибутиве Red Hat 4.0 обрывает подключение между запрашивающим адресом и сервером, если дается недопустимое имя пользователя. Однако если имя пользователя допустимо (но пароль неправилен), сервер допускает последующий вход в систему так, чтобы могла быть инициализирована повторная попытка. Выполняя хорошо захаканый сценарий Perl, взломщик может эффективно определить допустимые идентификаторы пользователей в вашей системе через своего рода методику "решения в лоб". Правда, Вы распознали бы это в ваших log-файлах через выполнение запросов на подключение от удаленного узла. Однако даже небольшие возможности, подобные этой, могут помочь постороннему в сборе информации о вашей системе.

Telnet радикально не отличается от других системных процессов. Она также была найдена уязвимой широкому диапазону нападений. Такие дыры периодически неожиданно возникают. Одна была обнаружена в 1995 Sam Hartman из Группы Разработчиков Kerberos в MIT (с подтверждением и программной помощью, обеспеченной John Hawkinson, также из MIT). Эта дыра была довольно неясной, но могла обеспечить удаленному пользователю корневой доступ. Как обсуждалось Hartman'ом в публичной консультации ("Telnet Vulnerability: Shared Libraries" - "Уязвимость Telnet: Общедоступные Библиотеки"):

В воскресенье, 15 октября, я обнаружил ошибку в некоторых версиях telnetd на некоторых платформах, которая позволяет пользователю, создающему подключение, заставить login загрузить альтернативную библиотеку C из произвольного места в файловой системе машины, выполняющей telnetd. В случае машин, устанавливающих распределенные файловые пространства типа AFS или NFS, содержащих публично записываемые анонимные каталоги FTP, или на которых пользователь уже имеет некорневую учетную запись, возможно получить корневой доступ.

Дыра, обнаруженная Hartman, была общей не только для одной версии telnetd, а для нескольких:

Затем обратите внимание. Если Вы плохо знакомы с UNIX, или если Вы выполняете систему без частой проверки списков ошибок на уязвимости, ваш telnetd может иметь эту проблему. Если так, Вы должны установить заплату. Свяжитесь с вашим поставщиком или посетите сайт вашего поставщика для заплат.

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

Ссылка: Вы можете прочитать "Telnet Vulnerability: Shared Libraries" в WWW на
http://geek-girl.com/bugtraq/1995_4/0032.html.

Более ранние версии Telnet также имели проблемы. Было бы плохой услугой с моей стороны, что перечислить их все здесь. Скорее, лучше предложить, чтобы Вы рассмотрели почему необходимо обеспечивать Telnet. Снова, это сводится к потребности. Если Вы можете избежать использования службы Telnet, то во что бы то ни стало сделайте так. Однако, если Вы должны предложить некоторую форму удаленного входа в систему, рассмотрите SSH.

Также, SSH не единственное ваше спасение. Я просто предполагаю, что на этом этапе мнимая машина, которую мы защищаем, еще не имеет брандмауэр или другие формы безопасности, применяемых к Telnet. Существуют другие возможности. Вот две из этих возможностей (обсуждаемых позже):

Что Вы будете использовать, зависит от ваших конкретных обстоятельств. В некоторых случаях (например, когда Вы ISP), действительно не возможно использовать общую исключающую схему. Нет никакой гарантии, что все Telnet подключения будут инициализированы из вашей подсети, ни что все будут исходить от ваших PPP пользователей. Некоторые из этих личностей будут на работе или в других местах. Они будут проверять свою почту за завтраком и так далее. Если Вы обеспечиваете shell службы, исключающие схемы непрактичны.

Исключение к этому, если Вы ограничили использование оболочки одной машиной (возможно машиной с именем shell.provider.com). В этой ситуации исключающие схемы могут быть осуществлены с некоторыми ограничениями. Возможно Вы имеете только 150 пользователей оболочки. Если так, Вы можете попросить, чтобы эти личности отправили Вам список вероятных адресов, с которых они будут входить. Адреса могут быть добавлены к списку допустимых узлов. Во многих случаях они могут входить с динамически распределяемых IP от различных поставщиков. В этом случае Вы должны сделать выбор, если Вы хотите позволить доступ всем пользователям этой сети. Обычно, однако, большинство пользователей оболочки будут регистрироваться с работы с фиксированным IP. Не было бы существенным усилием пропустить эти адреса через ваш фильтр.

Без установки любого из этого программного обеспечения принять решение, позволить ли Telnet трудно. Подобно большинству TCP/IP службам Telnet воздействуют на систему в целом. Например, многие экспедиций по взлому начинаются с Telnet. Взломщики могут проверить вашу уязвимость к нападениям переполнения и CGI эксплуатации, инициализируя сессию Telnet к порту 80. Они могут также пытаться подобрать допустимые имена пользователей, инициализируя сессию Telnet к порту 25 и так далее. (Кроме того, Telnet это один из путей для удаленного пользователя идентифицировать тип и версию вашей операционной системы. Это сообщит закаленному взломщику, какие дыры пробовать.)

Позвольте нам на мгновение предположить, что telnetd был заблокирован и Вы выбрали использовать SSH вместо него.

ПРИМЕЧАНИЕ: Одна дыра, стоящая вниманя, это методика передачи переменной окружения. Эта дыра появилась в ноябре 1995, и поэтому возможно, что она может воздействовать на вашу систему. Ошибка воздействовала даже на многие "безопасные" версии Telnet, которые использовали основанную на Kerberos аутентификацию. Поскольку ошибка была настолько серьезна (разрешая удаленным пользователям получать корневой доступ, еще одна дыра Класса A), Вы должны исследовать всю консультацию по ней. Методика включала передачу локальных переменных окружения удаленному адресату, использующему опцию ENVIRONMENT во всех версиях Telnet, соответствующих RFC 1408 или RFC 1572. Полная консультация находится на
http://ciac.llnl.gov/ciac/bulletins/g-01.shtml.

FTP

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

Анонимный FTP

Я против анонимного FTP, если у Вас нет причины для этого. Это главным образом, потому что FTP (подобно Telnet и большинству других протоколов) воздействует на всю систему:

Некоторые протоколы в сущности трудно фильтровать безопасно (например, RPC и UDP службы), таким образом обеспечивая большую открытость внутренней сети. Службы, поддерживаемые на той же самой машине, могут взаимодействовать катастрофическими способами. Например, позволяя анонимный FTP на той же самой машине, как и WWW сервер, можно позволить вторгшемуся разместить файл в анонимную область FTP и заставить HTTP сервер выполнить его.
Ссылка: Предыдущий параграф это выдержка из Site Security Handbook (Руководства по Безопасности Сайта) от Barbara Fraser (модифицированная и черновая версия; июнь 1996, CMU. draft-ietf-ssh-handbook-04.txt), которое может быть найдено в онлайне на
http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ssh-handbook-04.txt.

Ясно, что самая плохая ситуация, когда анонимный FTP имеет перезаписываемый каталог (например, /incoming). Полностью анонимный FTP с перезаписываемым каталогом делает Вас главной стоянкой для занимающихся методикой нападения FTP "рикошета".

Вкратце, методика рикошета FTP включает использование одного сервера FTP как маскировку, чтобы получить доступ к другому серверу FTP, который отказался от подключения со взломщиком. Типичная ситуация состоит в том, когда целевая машина сконфигурирована, чтобы отрицать подключения с некоторой иерархии IP адресов. Машина взломщика имеет IP адрес в пределах этой иерархии и поэтому некоторые, или все каталоги FTP на целевой машине недоступны ему. Так что взломщик использует другую машину ("посредник"), чтобы обратиться к адресату. Взломщик выполняет это, записывая в каталог FTP посредника файл, который содержит команды для соединения с адресатом и получения от него некоторого файла. Когда посредник соединяется с адресатом, то соединение исходит с его собственного адреса (а не взломщика). Адресат поэтому принимает запрос на подключение и передает требуемый файл.

Нападения рикошетом FTP не были первостепенными (или первоочередными) проблемами в кругах безопасности главным образом, потому что они редки и вообще не включают попытки взлома. (Большинство нападений рикошетом, вероятно, происходят за границей. Соединенные Штаты имеют экспортные ограничения на разнообразные продукты, чаще всего с шифрованием высокого уровня, содержащимися в программе. Нападения рикошетом предположительно используются для обхода ограничений Американских FTP сайтов.)

FTP Вобщем

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

О wu_ftpd

Если Вы используете версию wu_ftpd предшествующую апрелю 1993, Вы должны немедленно ее модифицировать. Как сообщено в Консультации CERT 93:06 ("wuarchive ftpd Vulnerability" - "Уязвимость wuarchive ftpd"):

Координационный Центр CERT получил информацию об уязвимости в версиях wuarchive ftpd доступных перед 8 апреля, 1993. Уязвимые версии wuarchive ftpd были доступны на wuarchive.wustl.edu:/packages/ftpd.wuarchive.shar и на многих других анонимных FTP сайтах ... Любой (удаленно или локально) мог потенциально получить доступ к любой учетной записи, включая корневую, на узле, выполняющем эту версию ftpd.

Это рассмотрение может первоначально показаться Вам бессмысленным из-за того, на сколько стары эти версии. Однако многие системы выполняют эти версии wu_ftpd. (Большинство из них это системы наследства. И снова, не все используют самые последние и самые лучшие версии.)

Это все, что касается более старых версий wu_ftpd. Теперь я хочу обсудить более новые. 4 января, 1997, в версии 2.4 была обнаружена ошибка (благодарности: Aleph1 и David Greenman) и зарегистрирована в Internet. Она является критической, потому что 2.4 наиболее широко используемая версия. Кроме того, она относительно нова. Если сейчас Вы используете 2.4 (и не слышали об этой ошибке), то должны немедленно приобрести заплату. Заплата была зарегистрирована в Internet David Greenman, главным архитектором Проекта FreeBSD. Во время этого написания заплата была доступна только в списке рассылки (BUGTRAQ). Также, во время этого написания, ошибка еще не была добавлена в доступную для поиска базу данных в BUGTRAQ. (Эта база данных расположена на http://www.geek-girl.com/bugtraq/search.html.) В соответствии с консультацией в начале этой книги о неавторизованной печати почты, я не буду печатать заплату здесь. Однако ко времени, когда эта книга дойдет до полок, регистрация будет заархивирована и может быть получена в BUGTRAQ используя следующие строки для поиска:

ПРИМЕЧАНИЕ: Эти строки должны быть введены точно так, как они напечатаны в списке.

В более общем смысле безопасность FTP это предмет, который будет лучше всего охвачен изучением технологии FTP в ее основе. Технология FTP значительно изменилась начиная с ее появления. Фактическая спецификация FTP была первоначально сформулирована в RFC 959, "File Transfer Protocol (FTP)" ("Протокол Передачи Файлов (FTP)") почти десятилетие назад. Начиная с того времени многое был сделано для улучшения безопасности этого критического приложения.

Документ, который Вы действительно должны получить, озаглавлен "FTP Security Extensions" ("Расширения Безопасности FTP"). Он был написан М. Horowitz (Cygnus Solutions) и S. J. Lunt (Bellcore). Этот IDraft (Internet draft - Internet черновик) был написан в ноябре 1996 и как сообщено в резюме этого черновика:

Этот документ определяет расширения спецификации FTP RFC 959, "File Transfer Protocol (FTP)" (октябрь 1985). Эти расширения обеспечивают сильную аутентификацию, целостность и конфиденциальность каналов управления и передачи данных с введением новых необязательных команд, ответов и кодирования передаваемых файлов.
Ссылка: "FTP Security Extensions" расположен на
http://info.internet.isi.edu/0/in-drafts/files/draft-ietf-cat-ftpsec-09.txt.

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

В завершение, есть несколько шагов, которые Вы можете предпринять, чтобы гарантировать, что ваш FTP сервер более безопасен:

В завершении я рекомендую строгую FTP регистрацию.

О TFTPD

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

ПРИМЕЧАНИЕ: Некоторые версии явно не безопасны. Одна из них это TFTP, обеспеченный в AIX версии 3.x. Номер заплаты для него ix22628. Очень маловероятно, что Вы используете такую устаревшую версию AIX. Однако если Вы приобрели старый RS/6000, примите во внимание эту проблему, которая позволяет удаленным пользователям захватывать /etc/passwd.

В Главе 9, "Сканеры", я обсуждал TFTP и сканер, сделанный специально для обнаружения открытых TFTP дыр (CONNECT). Поскольку знание TFTP уязвимостей настолько широко распространено, есть очень немного системных администраторов, которые выполняют его. Не будьте исключением из этого правила.

ПРИМЕЧАНИЕ: Возможно Вы думаете, что число личностей, которые могут эксплуатировать TFTP, мало. В конце концов, это требует некоторого приличного знания UNIX. Или нет? Проверьте TFTPClient32 для Windows 95. Эта утилита может помочь взломщику (с минимальным знанием UNIX) взломать ваш TFTP сервер. Вы можете загрузить копию с
http://papa.indstate.edu:8888/ftp/main!winsock-l!Windows95!FTP.html.

Отключение TFTPD это тривиальный вопрос (никакой преднамеренной игры слов*2). Вы просто комментируете его в inetd.conf, таким образом предотвращая его от выполнения при загрузке. Однако если Вы намерены выполнять TFTP, есть несколько вещей, которые Вы могли бы рассмотреть:

ПРИМЕЧАНИЕ: Если Вы плохо знакомы с UNIX (вероятно пользователь Linux), я предлагаю Вам прочитать man страницы по TFTP. Если, будучи плохо знакомым с UNIX, Вы не выбрали установку man страниц (и другой документации), то должны по крайней мере посетить эти страницы:

http://flash.compatible.com/cloop-html/tftp.html

http://www.hds.com/htmlsysadmin/2-3-1.html

http://www.iss.net/vd/vuln/misc/tftp1.html

...

Все эти страницы обсуждают слабости в дистрибутиве TFTP. Кроме того, я предлагаю Вам приобрести копию RFC 1350, который является официальной спецификацией TFTP. Наиболее надежный сайт для него, который я знаю, это
http://www.freesoft.org/Connected/RFC/1350/.

Gopher

Gopher сейчас несколько устаревший протокол. Однако он быстр и эффективен. Если Вы выполняете его, снимаю шляпу перед Вами. Я большой фанат Gopher, потому что он поставляет информацию на мой стол почти мгновенно (в противоположность сетевым службам HTTP, которые уже полностью насыщены).

Gopher не был традиционно слабой службой с точки зрения безопасность, но есть некоторые проблемы достойные упоминания. Gopher сервера Университета Mиннесоты вероятно наиболее популярный Gopher сервер из когда-либо написанных (доступен на boombox.micro.umn.edu). Я оценил бы, что даже сегодня больше половины всех Gopher серверов выполняют некоторую версию этого популярного продукта. Из них вероятно 10 процентов уязвимы старой ошибке. Эта ошибка присутствует и в Gopher и Gopher+ всех версий, приобретенных до августа 1993. Как сообщено в Консультации CERT CA-93:11, "UMN UNIX Gopher and Gopher+ Vulnerabilities" ("Уязвимости UMN UNIX Gopher и Gopher+"):

Вторгшиеся, как известно, эксплуатируют эти уязвимости, чтобы получить файлы паролей ... . Любой (удаленно или локально) может потенциально получить неограниченный доступ к учетной записи, выполняющей общественно доступного клиента, таким образом получая возможность читать любые файлы, доступные для этой учетной записи (возможно включая /etc/passwd или другие чувствительные файлы) ... . В некоторых конфигурациях любой (удаленно или локально) может потенциально получить доступ к любой учетной записи, включая root, на узле, сконфигурированном как сервер, выполняющий gopherd.

Эта дыра была также описана в Бюллетене Военной Сети Передачи Данных (Бюллетень Безопасности DDN 9315, 9 августа, 1993), который может быть просмотрен на
http://www.arc.com/database/Security_Bulletins/DDN/sec-9315.txt.

Я думаю, что большинство взломщиков знают немного о Gopher. Однако есть некоторые хорошо известные ошибки. Одна состоит в том, что Gopher может уполномачивать сессию FTP и поэтому, даже если Вам ограничен доступ к каталогу FTP на машине, Вы выполняете нападение рикошетом, используя Gopher как панель запуска. Это представляет небольшую проблему относительно безопасности брандмауэра. Например, если сетевой FTP сервер находится позади брандмауэра, но Gopher сервер нет (и они принадлежат одной и тойже сети), блокирование доступа к FTP серверу не будет означать ничего.

В его состоянии по умолчанию Gopher имеет очень бедные возможности регистрации, по сравнению с другими сетевыми службами. И в то время как проблема FTP уполномачивания не полностью критическая, это то, что необходимо помнить.

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

Сетевая Файловая Система

Многие люди критикуют Сетевую Файловую Систему (NFS - Network File System), потому что ее история в безопасности была запятнана. Однако выгоды от использования NFS значительны. Проблема находится в методе аутентификации для небезопасной NFS. Просто не достаточно контроля над тем, кто может генерировать "допустимый" NFS запрос.

Проблема не столько в NFS непосредственно, как в мастерстве системного администратора. Экспортируемые файловые системы могут или не могут представлять риск, в зависимости от того, как они экспортируются. Разрешения большой фактор. Конечно, если Вы имеете причину полагать, что ваши пользователи собираются генерировать (даже тайно) свои собственные файлы .rhosts (то, что Вы должны явно запретить), экспортирование /export/home очень плохая идея, потому что эти каталоги будут естественно содержать разрешения для чтение/записи.

Некоторые утилиты могут помочь Вам автоматизировать процесс исследования (и закрытия) дыры NFS. Одна из них это NFSbug, написанная Leendert van Doorn. Эта утилита (обычно распространяемая как файл shar) предназначен для сканирования общеизвестных дыр NFS. Прежде, чем Вы закончите ревизию вашей безопасности и разместите машину на основной улице, я предлагаю выполнить эту утилиту против вашей системы (прежде, чем это сделают взломщики). NFSbug доступна на
ftp://ftp.cs.vu.nl/pub/leendert/nfsbug.shar.

СОВЕТ: Для превосходной иллюстрации того, как взломщики нападают на NFS, Вы должны получить документ "Improving the Security of Your Site by Breaking Into It" ("Улучшение Безопасности Вашего Сайта Вторжением В Него") (Dan Farmer и Wietse Venema). В этом документе содержится пошаговый анализ такого нападения. Этот документ может быть надежно получен на
http://www.craftwork.com/papers/security.html.

ПРЕДОСТЕРЕЖЕНИЕ: Никогда не обеспечивайте доступ для записи NFS к привилегированным файлам или областям и не делайте их общедоступными в Сети. Если Вы делаете так, то напрашиваетесь на неприятности. Попытайтесь сохранить все только для чтения.

Пожалуйста не предполагайте, что NFS редко используется взломщиками. Как сообщено в Консультации Военной Сети Передачи Данных от 1995, проблемы NFS продолжают происходить:

РЕЗЮМЕ: Увеличение сообщений о компрометации root вызванно злоумышленниками, использующими утилиты для эксплуатации множества уязвимостей Сетевой Файловой Системы (NFS - Network File System) ... Существуют утилиты, используемые злоумышленниками, для эксплуатации множества уязвимостей NFS и получения неавторизованного доступа к сетевым ресурсам. Эти утилиты и связанная с ними информация широко распространены на многочисленных форумах Internet.
Ссылка: Предыдущий параграф это выдержка из Бюллетеня Безопасности DDN 9501, который может быть найден в онлайне на
ftp://nic.ddn.mil/scc/sec-9501.txt.

Я избегал бы выполнения NFS. В ней есть некоторые проблемы. Одна из них в том, что даже если Вы используете "расширенную" или "безопасную" NFS (то есть форму NFS, которую использует DES при аутентификации), все равно можете встретиться с неприятностью. Ключ DES может быть получен из пароля пользователя. Это представляет очевидную проблему. Принимая, что затенение установлено на машине, это может представлять один путь для взломщика, чтобы получить распечатки passwd. Единственное реальное значение расширенных версий DES в том, что алгоритм получает время. Процедуры с временными метками устраняют возможность взломщика контролировать обмен и позже воспроизводить его.

ПРИМЕЧАНИЕ: Вы можете блокировать трафик NFS на уровне маршрутизатора. Вы делаете это применяя фильтрацию к портам 111 и 2049. Однако это может иметь небольшое или вообще никакого влияния на взломщиков, которые находятся внутри вашей сети. Я предпочитаю комбинацию этих методов. То есть если Вы выполняете NFS, используйте расширенную версию с DES аутентификацией также как основанную на маршрутизаторе схему блокирования-отрицания.

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

HTTP

В наши дни HTTP выполняется более часто чем любой другой протокол, прежде всего, потому что WWW стала такой популярной издательской средой. В общем случае, HTTP не является безопасным. Однако есть некоторые вещи, которые Вы должны знать. Проблема номер один не в HTTP вообще, а в системном администраторе, обеспечивающим службу. Не выполняйте httpd как root! Если Вы не учтете этот совет, то будете очень грустным системным администратором. Даже самая небольшая слабость в CGI программе может означать полную компрометацию вашей системы, если Вы выполняете httpd как root. Это означает, что удаленные пользователи могут выполнять процессы как корневые.

Кроме того, хотя я обращаюсь к безопасности CGI позже в этой книге, вот некоторый твердый совет: Если Вы ответствены за написание CGI программ, будте внимательны и исследуйте код очень близко. Существует ли возможность, что кто-то может поместить команды в стек, используя метасимволы?

Также, рассмотрим возможность выполнения httpd как процесса chroot. Многие консультации говорят, что это обеспечит большую безопасность. По моему мнению, httpd не должен работать в среде chroot. Во-первых, это предлагает только очень минимальные достижения безопасности и строго ограничивает вашу способность использовать CGI. Например, при нормальных обстоятельствах пользователи могут выполнять программы CGI из их собственной структуры каталогов. Под этим я подразумеваю, что стандартная процедура, когда пользователи могут выполнять CGI, скажем, из TT>/~usr/public_html/cgi-bin или некоторого подобного каталога, который был идентифицирован как домашний cgi-bin каталог пользователя. Если Вы выполняете httpd в среде chroot, ваши пользователи не будут способны выполнять эти сценарии, если они также не находятся в среде chroot. Кроме того, достижения безопасности в лучшем случае случайны. Для того, чтобы позволить некоторую форму CGI на вашей машине, Вы были бы должны также выполнять или интерпретатор Perl или C-основанные двоичные образы из среды chroot. А это противоречит нашей цели. Если Вы не чувствуете, что есть абсолютная потребность выполнять httpd в среде chroot, я привожу доводы против выполнения. Это делает доступ слишком ограниченным, чтобы эффективно обеспечивать CGI.

Одна ценная программа, которая может помочь Вам в тестировании CGI приложений это CGIWRAP, которая является относительно новой программой делающей следующее:

CGIWRAP была написана Nathan Neulinger и выпущена в 1995. Она доступна в различных местах в Сети. Я нашел, что это место будет надежным:
ftp://ftp.cc.umr.edu/pub/cgi/cgiwrap/.

Сообщено, что работа CGIWRAP была проверена на следующих платформах:

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

В различных реализациях HTTP могут быть найдены специфические проблемы, главным образом в серверах. Один из таких серверов NCSA httpd. Например, версия 1.3 имела уязвимость переполнения буфера. Если Вы используете или будете использовать 1.3, немедленно обновите ее. Для информации по воздействию на проблему посетите эти источники:

Вы можете предпринять некоторые основные меры предосторожности:

Также, обратите внимание на предупреждение NCSA относительно основанной на DNS аутентификации:

Управление доступом именем узла и основными средствами аутентификации пользователя, обеспеченные HTTPd, относительно безопасны, но не пуленепробиваемы. При аутентификации пользователя по сети посылаются пароли в открытом тексте, что делает их легко читаемыми. Основанное на DNS управление доступом на столько же безопасно, как и DNS, так что Вы должны помнить это при его использовании. Нижняя строка: Если это абсолютно точно не может быть замечено внешними людьми, Вы вероятно не должны использовать HTTPd, чтобы защитить ее. - "NCSA Tutorial Pages: Making Your Setup More Secure" ("Справочные Страницы NCSA: Получение Вашей Установки Более Безопасной"),
http://hoohoo.ncsa.uiuc.edu/docs/tutorials/security.html.

Безопасность HTTP в Общем

Безопасность HTTP подверглась многим изменениям, особенно за два последних года. Одно из них это разработка более безопасных httpd серверов. (В прошлом с серверами были разнообразные проблемы, включая, но не ограничиваясь, проблемами с переполнениями стека и плохими CGI.) Другие были в области разработки конкретных решений безопасности для всего протокола. Несколько важных предложений выделены в следующих разделах.

Безопасный Протокол Передачи Гипертекста

Безопасный Протокол Передачи Гипертекста (S-HTTP - Secure Hypertext Transfer Protocol) был разработан Enterprise Integration Technologies (подразделением VeriFone, часть Подразделения VeriFone по Internet Торговле). S-HTTP включает основанные на RSA и Kerberos шифрование и аутентификацию. Как описано в IDraft по S-HTTP:

Безопасный HTTP (S-HTTP) это расширение HTTP, обеспечивающее независимые от применения безопасные службы для конфиденциальности транзакций, подлинности/целостности и не repudiability оригинала. Протокол подчеркивает максимальную гибкость в выборе ключевых механизмов управления, политик безопасности и криптографических алгоритмов, поддерживая опции согласования между сторонами для каждой транзакции. - E. Rescorla и A. Schiffman, "Безопасный Протокол Передачи Гипертекста", июль 1995,
http://www.eit.com/creations/s-http/draft-ietf-wts-shttp-00.txt.

Основанные на RSA и Kerberos аутентификация и шифрование довольно сильная смесь.

Протокол Уровня Безопасных Разъемов

Уровень Безопасных Разъемов (SSL - Secure Sockets Layer) это метод, придуманный людьми из Netscape. Система представляет трехуровневый метод обеспечения двухсторонних подключений. Система использует RSA и DES аутентификацию и шифрование также как дополнительную проверку целостности MD5. Вы захотите узнать больше об этой системе, и поэтому Вы должны посетить домашнюю страницу SSL. Этот документ, озаглавленный "The SSL Protocol" ("Протокол SSL") (IDraft) был создан Alan O. Freier и Philip Karlton (Netscape Communications) с Paul C. Kocher. Он расположен на
http://home.netscape.com/eng/ssl3/ssl-toc.html.

Очень интересный документ по HTTP безопасности "Evaluating Hypertext Servers for Performance and Data Security" ("Оценка Гипертекстовых Серверов на Производительность и Безопасность Данных") (Suresh Srinivasan, Старший Исследователь, Сервисная Группа Thomson Technology). В нем автор противопоставляет множество предложений безопасности или стандартов для HTTP и HTML.

Безопасность HTTP еще новая область. Смотрите Главу 30, "Язык, Расширения и Безопасность", для дальнейшей информации.

Сохранение Файловой Системы

Прежде, чем фактически подключить эту машину к Internet (или любой сети по вашему выбору), Вы захотите выполнить резервное копирование. Это сохранит файловую систему какой она была после инсталляции. В зависимости от того, насколько система большая (возможно Вы установили все), Вы могли бы хотеть избежать использовать ленту. Я рекомендую копировать систему на floptical, Jazz диски или даже на старый SCSI диск, который Вы имеете под рукой. Я предлагаю это, потому что восстановление будет быстрее. Если Вы подозреваете, что было вторжение, то сможете сделать по крайней мере сравнение настолько быстро, насколько это возможно. Однако, даже если Вы не обеспокоены скоростью, я предлагаю сделать резервную копию на носителе, который не доступен другим пользователям. Резервная копия должна находится в месте, которое доступно только Вам или доверенному персоналу.

После Резервного Копирования: Установка TCP_WRAPPERS, TCP_Dump и Tripwire

В этом этапе Вы сделали следующее:

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

TCP_WRAPPERS

TCP_WRAPPERS это программа, написанная Wietse Venema. Похоже, что никакая другая утилита не делает настолько легким или эффективным контроль подключений с вашей машиной. Программа работает заменяя системные демоны и производя запись всех запросов на подключение, их времени, и что наиболее важно, их происхождения. По этим причинам TCP_WRAPPERS одна из наиболее критических к сбору доказательств утилит. А также она свободна. (Часто лучшее программное обеспечение UNIX является свободным.)

Перед установкой TCP_WRAPPERS Вы должны прочитать документ, который объявил о существовании программы. Этот документ (озаглавленный "TCP WRAPPER: Network Monitoring, Access Control, and Booby Traps" - "TCP WRAPPER: Контроль Сети, Управление Доступом и Ловушки") может быть найден на http://www.raptor.com/lib/tcp_wrapper.ps. Документ важен по нескольким причинам. Во первых, он показывает что TCP_WRAPPERS может сделать для Вас. Во вторых, он включает пример из реальной жизнью, немного захватывающий рассказ (дополненный log-файлами) об усилиях Venema по выявлению и предчувствованию взломщика.

ПРИМЕЧАНИЕ: Подобно наиболее хорошим приложениям безопасности TCP_WRAPPERS вырос из потребности. Очевидно, Университет Технологий Eindhoven, где находится Venema, подвергся значительному нападению взломщика. Нападения были особенно коварны и потрясающи, потому что взломщик часто удалял все с жестких дисков машин, которые он компрометировал. (Естественно, как Venema отражает в документе, было трудно определить что нибудь относительно нападений, потому что данные были стерты.) Решение существовало и Venema нашла его: Создала демон, который прерывал любой запрос на подключение, делал запись запроса и его происхождения, и затем передавал этот запрос к родным системным демонам. Чтобы выяснить, что произошло, получите документ. Это интересная история.

Ссылка: TCP_WRAPPERS может быть получен из многих мест в Internet, но я предпочитаю его дом:
ftp://ftp.win.tue.nl/pub/security/TCP_WRAPPERS_7.4.tar.gz.

TCP_WRAPPERS прост в установке на большинстве платформ UNIX, требует для работаты очень мало ресурсов, и может обеспечить обширные log-файлы того, кто обращается к вашей системе. Короче говоря, эта программа является обязательной. Для справки по реализации и разработке, пожалуйста получите документ, описанный ранее.

TCP_Dump

Люди серьезно занимающиеся безопасностью несомненно расплывутся в улыбке при упоминании TCP_Dump. Это большая утилита, использующаяся для анализа трафика в вашей сети. Это также программа, которую Shimomura выполнял в своей сети, когда Kevin Mitnik предположительно осуществил успешное нападение обманном против нее. Журналисты был поражены тем, как Shimomura получил детальную информацию по нападению. Никакого волшебства, он просто выполнял TCP_Dump.

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

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

ПРЕДОСТЕРЕЖЕНИЕ: Только напомню Вам, что программы подобные TCP_Dump могут в конечном счете съесть много пространства на жестком диске, в зависимости от частоты трафика в вашей сети. Если Вы планируете иметь много трафика, то можете рассмотреть "сокращение" уровня перехвата, который TCP_Dump фактически производит. Она имеет различные опции, которые позволяют Вам ограничивать "прослушывание" некоторыми протоколами, какими Вам нравится. Одинаково, Вы можете выполнять программу "на полную катушку", тогда я рекомендовал бы для вывода хороший RAID. (Это шутка, конечно, если ваша сеть не очень большая и не часто посещается сотнями людей.)

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

TripWire

Затем, Вы захотите установить TripWire. Я обсуждал TripWire в предыдущих главах, так что здесь я не буду охватывать ее интенсивно. Я уже дал указания о том, где она расположена. Здесь я предлагаю, чтобы Вы приобрели следующие документы:

Другие Утилиты

TripWire не единственный Ваш выбор для согласования файлов и системы. Одна утилита, которая получила очень хорошие оценки, называется binaudit. Она была написана Matt Bishop, также автора passwd+. Эта система более часто упоминается как RIACS Auditing Package (Ревизорский Пакет RIACS).

Ссылка: Вы можете найти binaudit на
ftp://nob.cs.ucdavis.edu/pub/sec-tools/binaudit.tar.

Система работает с основным списком значений файлов, которые поддерживаются в файле /usr/audit/audit.lst. Эта система не столь же всесторонняя как TripWire, но требует очень низкие затраты и минимум проблем при установке и обслуживании.

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

О X

Безопасность Системы X Window неясная, но одна из важных областей. Если Вы еще раз исследуете Список Оцененных Программ, то увидите, что основанные на X Window продукты не встречаются. Система X Window вероятно наиболее гибкая, сетевая оконная система из когда-либо разработанных, но ее безопасность имеет плохую репутацию.

Основной аргумент против использования X это дыра xhost. Когда X сервер отключает управления доступом, любой откуда нибудь из Internet может открыть дополнительные X окна и начать выполнять произвольные программы. Эта дыра может быть легко закрыта (фактически есть различия между xhost + и xhost -), но люди все еще сдержано относятся к разрешению удаленных X сессий. (Опять, это все касается плохого администрирования, а не плохого проектирования программы.)

Чтобы исправить проблему были предприняты некоторые интересные подходы. В следующем разделе я акцентирую внимание на некоторых проблемах безопасности Системы X Window. Чтобы сделать это я буду использовать отрывки из различных документов. Содержание этих документов это то, что Вам действительно необходимо. Снова, как я упомянул в начале, эта книга является для Вас дорожной картой. Если у Вас есть практический интерес к безопасности X, то Вы захотите получить каждые из цитируемых документов.

Как отмечено G. Winfield Treese и Alec Wolman в их документе "X Through the Firewall and Other Application Relays" ("X Через Брандмауэр и Другие Ретрансляционные Приложения"):

В Системе X Window базовая модель безопасности позволяет пользователю управлять набором узлов, которым разрешено подключение с X сервером. Этот управление воздействует только на новые подключения, не на существующие. Многие пользователи полностью отключают управление доступом для личного удобства при использовании больше чем одного узла.

Первый момент, что X не просто система управления окнами. Она выглядит и ведет себя очень похоже на разнообразные системы управления окнами, но это только часть картины. X серверу посылаются подключения. X сервер может обслужить любого допустимого X клиента, находтся этот клиент на той же самой машине или за мили от нее. Как отмечено John Fisher в его статье "Securing X Windows" ("Безопасность X Window"):

X Window вдействительности на самом низком уровне является протоколом связи, названном достаточно разумно, X Протокол. Этот протокол используется в пределах единственного компьютера или сети компьютеров. Он не привязан к операционной системе и доступен на широком диапазоне платформ. X Window используют Клиент-Серверную модель сетевой связи. Эта модель позволяет пользователю выполнять программу в одном месте, а управлять ею из другого места.

Поэтому, X очень похож на любой другой протокол в UNIX. Он работает по модели клиент/сервер и обеспечивает доступ через Internet и множество систем и архитектур. Важно, чтобы пользователи плохо знакомые с UNIX понимали это. Когда допустимое подключение инициализировано, может случиться все что угодно (как отмечено на странице руководства X11R5 Xserver):

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

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

Процесс, которым безопасность поддерживается в X, полагается на Magic Cookie. Это 128-разрядное значение, сгенерированное псевдослучайным способом. Это значение распространяется клиентам и сохраняется в файле .Xauthority. Эта схема аутентификации известна как мера "средней силы" ("medium strength") и может теоретически быть обойдена. Она считается слабой по следующим причинам:

Хотя механизм XDM-AUTHORIZATION-1 предлагает достаточную защиту против людей, пробующих захватить аутентификационные данные из сети, все равно существует основная проблема: весь механизм безопасности зависит от защиты файла .Xauthority. Если другие люди смогут получить доступ к содержанию вашего файла .Xauthority, они узнают ключ, используемый для шифрования данных, и безопасность будет нарушена.
Ссылка: Предыдущий параграф это выдержка из статьи Francois Staes, которая появилась в The X Advisor. Статья, озаглавленная "X Security" ("Безопасность X"), может быть найдена в онлайне на
http://www.unx.com/DD/advisor/docs/nov95/nov95.fstaes.shtml.

Правда, если Вы позволили управление доступом маловероятно, что посторонний захватит ваш файл .Xauthority. Однако Вы не должны пологаться на простое управление доступом, чтобы предотвратить проникновение в вашу сеть. Должы быть предприняты усилия, чтобы поддержать X безопасность и нет никакой причины, по которой Вы не должны воспользоваться их преимуществом. Должны быть предприняты дополнительные меры безопасности, потому что основа схемы безопасности X раньше была определена как недоработанная. Как отмечено в бюллетене CERT озаглавленном "X Authentication Vulnerability" ("Уязвимость X Аутентификации"):

Две широко используемых в Системе X Window схемы разрешения имеют слабости в типовой реализации. Эти слабости могут позволить неавторизованным удаленным пользователям соединяться с X дисплеями и присутствуют в X11 Выпуск 6 и более ранних выпусках X11. Есть сообщения, что системы повреждались используя по крайней мере одну из этих слабостей и что теперь есть эксплуатирующие их программы, доступные в сообществе злоумышленников.

Кроме того, есть много программ (типа xkey, xscan, xspy и watchwin), которые автоматизируют задачу взлома X сервера или эксплуатации сервера после его взлома. Так что я посоветовал бы не выполнять X в Internet или даже в сети. По моему опыты маленькие компании редко имеют допустимые причины, чтобы выполнять X серверы на своих машинах (по крайней мере не на машинах, связанных с Internet).

Однако, если Вы настаиваете на выполнении X этим способом, есть некоторые шаги, которые Вы можете предпринять. Например, Farmer и Venema предлагают по крайней мере удалить все образцы xhost + не только из главного Xsession файла, но и из всех файлов .xsession в системе. (Конечно Вы могли запретить создание любого такого файла. Однако, фактически, пользователи могут игнорировать Вас. Я бы периодически выполнял сценарий, возможно достаточно часто, чтобы сделать его заданием cron, который находил бы эти нарушения.)

Другие источники предлагают возможное использование Kerberized Xlib или Протокола Идентификации (Identification Protocol), определенного в RFC 1413. Ваш выбор будет зависеть от вашей конкретной сетевой конфигурации. К сожалению о безопасности системы X Window можно написать целую книгу, так что я просто скажу, что перед принятием решения о выполнении X серверов в вашей сети, загрузите документы, которые я уже процитировал. Они (и документы, которые я собираюсь цитировать) помогут Вам принять информированное решение. Вот некоторые советы относительно безопасности X:

Публикации

X Window System Security (Безопасность Системы X Window). Ben Gross и Baba Buehler. Системные Службы Института Beckman.

On the (in)Security of the Windowing System X (О (не)Надежности X Системы Управления Окнами). Marc VanHeyningen. Университет Штата Индиана. 14 сентября, 1994.

Security in the X11 Environment (Безопасность в Среде X11). Университет Бристоля, UK. Январь 1995.

Security in Open Systems (Безопасность в Открытых Системах). John Barkley, редактор (с Lisa Carnahan, Richard Kuhn, Robert Bagwill, Anastase Nakassis, Michael Ransom, John Wack, Karen Olsen, Paul Markovitz и Shu-Jen Chang). Министерство Торговли Америки, Раздел: Система X Window: Bagwill, Robert.

Security Enhancements of the DEC MLS+ System: The Trusted X Window System (Расширения Безопасности Системы DEC MLS+: Доверенная Система X Window). Ноябрь 1995.

Evolution of a Trusted B3 Window System Prototype (Развитие Прототипа Доверенной Оконной Системы B3). J. Epstein, J. McHugh, R. Pascale, C. Martin, D. Rothnie, H. Orman, A. Marmor-Squires, M. Branstad и B. Danner. Протоколы 1992 IEEE Симпозиума по Безопасности и Секретности, 1992.

A Prototype B3 Trusted X Window System (Прототип B3 Доверенной Системе X Window). J. Epstein, J. McHugh, R. Pascale, H. Orman, G. Benson, C. Martin, A. Marmor-Squires, B. Danner и M. Branstad. Протоколы 7-ой Конференции по Приложениям Компьютерной Безопасности. Декабрь 1991.

Improving X Window Security (Улучшение Безопасности X Window). Linda Mui. UNIX World 9(12). Декабрь 1992.

Security and the X Window System (Безопасность и Система X Window). Dennis Sheldrick. UNIX World 9(1):103. Январь 1992.

The X Window System (Система X Window). Robert W. Scheifler и Jim Gettys. ACM Transactions on Graphics, (5)2:79-109. Апрель 1986.

X Window Terminals (Терминалы X Window). Björn Engberg и Thomas Porcher. Цифровой Технический Журнал Digital Equipment Corporation, 3(4):26-36. Осень 1991.

Заплаты

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

Всесторонний список всех заплат и их местоположений вне области этой книги. Однако следующее это несколько важных ссылок:

Ссылка: Заплаты для операционных систем Sun и Solaris могут быть найдены на
ftp://sunsolve1.sun.com/pub/patches/.

Заплаты для операционной системы HP-UX могут быть найдены на
http://support.mayfield.hp.com/patches/html/patches.html.

Заплаты для Ultrix могут быть найдены на
ftp://ftp.service.digital.com/pub/ultrix/.

Заплаты для операционной системы AIX могут быть найдены на
ftp://software.watson.ibm.com.

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

Соединение Машины с Internet: Последние Шаги

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

Вашы политики и процедуры будут сильно меняться в зависимости от того, для чего используется ваша сеть и кто использует ее. Прежде, чем Вы соединяетесь с Сетью (или любой другой сетью), Вы должны иметь набор политик и процедур. По моему мнению, они должны быть записаны. Люди придерживаются вещей более строго, когда они записаны. Также, если Вы далеко и назначили кого-то еще следить за машиной (или сетью), этот человек может быстро сослаться к вашей политике и процедурам.

Многие компании и организации не имеют таких политик и процедур, и это ведет к беспорядку и разногласию среди управляющего персонала. (Кроме того, недостаток письменной политики существенно ослабляет безопасность и время реагирования.)

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

Ссылка: RFC 1244 расположен на
http://www.net.ohio-state.edu/hypertext/rfc1244/intro.html.

Другой интересный источник (и другой взгляд) по политикам и процедурам безопасности это проспект Сети Защиты Данных озаглавленный "COMMUNICATIONS SECURITY: DDN Security Management Procedures for Host Administrators" ("БЕЗОПАСНОСТЬ СВЯЗИ: Процедуры Управления Безопасностью DDN для Администраторов узлов"). Он определяет некоторые из мер, предпринятых DDN.

Ссылка: "COMMUNICATIONS SECURITY: DDN Security Management Procedures for Host Administrators" расположен на
http://csrc.ncsl.nist.gov/secalert/ddn/DCA_Circular.310-P115-1.

Другой, более новый и более всесторонний документ озаглавлен "Protection of TCP/IP Based Network: Elements: Security Checklist Version 1.8" ("Защита Сети Основанной на TCP/IP: Элементы: Контрольный Список Безопасности Версия 1.8"), написанный Dale Drew из MCI. Этот документ быстрый контрольный список, который охватывает не только политики и процедуры, но и все элементы сетевой безопасности. Это превосходное начало.

Ссылка: "Protection of TCP/IP Based Network: Elements: Security Checklist Version 1.8" расположен на
http://www.security.mci.net/check.html.

Наконец, в конце этой главы, приведен список публикаций, журналов, Web страниц и книг, в которых Вы можете найти ценную информацию по установке политик пользователей.

Публикации

Practical UNIX and Internet Security (Second Edition) (Практическая Безопасность UNIX и Internet (Второе Издание)). Simson Garfinkel и Gene Spafford. 1996. O'Reilly & Associates, Inc. ISBN 1-56592-148-8.

UNIX Security: A Practical Tutorial (Безопасность UNIX: Практический Справочный Документ). McGraw-Hill. N. Derek Arnold. 1993. ISBN 0-07-002560-6.

UNIX System Security (Безопасность UNIX Системы). Addison-Wesley Publishing Company, Inc. David A. Curry. 1992. ISBN 0-201-56327-4.

UNIX System Security (Безопасность UNIX Системы). Addison-Wesley Publishing Company, Inc. Rick Farrow. 1990. ISBN 0-201-57030-0.

The Cuckoo's Egg (Яйцо Кукушки). Cliff Stoll. Doubleday. ISBN 0-385-24946-2. 1989.

UNIX System Security (Безопасность UNIX Системы). Patrick H. Wood и Stephen G. Kochan. Hayden Books. ISBN 0-8104-6267-2. 1985.

Computer Security Basics (Основы Компьютерной Безопасности). Deborah Russell и G. T. Gangemi, Sr. O'Reilly & Associates, Inc. ISBN 0-937175-71-4. Июль 1991.

Computer Crime: A Crimefighter's Handbook (First Edition) (Компьютерное Преступление: Руководство Crimefighter'а (Первое Издание)). David Icove, Karl Seger и William VonStorch; Консультационный Редактор Eugene H. Spafford. ISBN 1-56592-086-4. Август 1995.

Следующий Шаг

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

http://ciac.llnl.gov/ciac/documents/CIAC-2308_Securing_Internet_Information_Servers.pdf
..
http://ciac.llnl.gov/ciac/documents/CIAC-2316_Securing_X_Windows.pdf
..
http://ciac.llnl.gov/ciac/documents/CIAC-2307_Electronic_Resources_for_Security_Related_Information.pdf
..
ftp://caliban.physics.utoronto.ca/pub/unix_security_checklist_1.1
..
http://www.raptor.com/lib/csl94-01.txt
..

Заключение

У Вас есть еще одна задача. Вернитесь к Главе 9, приобрет