Справочник по безопасности сетевого узла Зам. зав. кафедры "Телекоммуникационные сети и системы" МФТИ Зам.зав. кафедры Информатики ФНТИ МФТИ Нач. лаб. Инфокоммуникационных технологий Института Теоретической и Экспериментальной Физики (semenov@itep.ru) (RFC-2196, B. Fraser, сентябрь 1997) 1. Введение Этот документ предоставляет собой руководство для системных и сетевых администраторов в сфере определения безопасной работы в условиях подключения к Интернет. Он построен на основе RFC-1244 и является результатом коллективного труда большого коллектива авторов. Среди них: Jules P. Aronson (aronson@nlm.nih.gov), Nevil Brownlee (n.brownlee@auckland.ac.nz), Frank Byrum (byrum@norfolk.infi.net), Joao Nuno Ferreira (ferreira@rccn.net), Barbara Fraser (byf@cert.org), Steve Glass (glass@ftp.com), Erik Guttman (erik.guttman@eng.sun.com), Tom Killalea (tomk@nwnet.net), Klaus-Peter Kossakowski (kossakowski@cert.dfn.de), Lorna Leone (lorna@staff.singnet.com.sg), Edward.P.Lewis (Edward.P.Lewis.1@gsfc.nasa.gov), Gary Malkin (gmalkin@xylogics.com), Russ Mundy (mundy@tis.com), Philip J. Nesser (pjnesser@martigny.ai.mit.edu), и Michael S. Ramsey (msr@interpath.net). В дополнения к авторам документа следует упомянуть несколько его рецензентов предоставивших ценные комментарии. В этот список входят: Eric Luiijf (luiijf@fel.tno.nl), Marijke Kaat (marijke.kaat@sec.nl), Ray Plzak (plzak@nic.mil) and Han Pronk (h.m.pronk@vka.nl). 1.1. Цель данной работы Данный справочник является руководством по определению процедур и политики безопасности для узлов, которые имеют связи с Интернет (однако, предлагаемая информация может оказаться полезной и для узлов, которые пока не соединены с Интернет). Данное руководство перечисляет моменты и факторы, которые следует рассмотреть, при определении своей собственной политики. Данный справочник предоставляет лишь общие рамки определения политики и процедур безопасности. Для того чтобы достичь эффективности набора процедур и политики, в узле должно быть принято много решений, достигнуто ряд соглашений, после чего это все должно быть успешно внедрено в практику коммуникаций. 1.2 Аудитория Аудиторией этого документа являются системные и сетевые администраторы, а также лица, принимающие решения в сетевых узлах (обычно "средний уровень менеджмента"). Короче, мы будем использовать термин "администратор" в рамках данного документа, подразумевая системного и сетевого администратора. Данный документ не ориентирован на программистов или тех, кто пытается писать программы для безопасности или строит такие системы. Основное внимание здесь уделяется политике и процедурам, которые необходимы для поддержания параметров технической безопасности узла. В первую очередь аудиторией документа являются узлы, подключенные к Интернет. Однако этот документ может быть полезен для любого узла, который допускает соединения с другими узлами. 1.3. Определения В данном руководстве под "узлом" подразумевается любая организация, которая имеет ЭВМ или сетевые ресурсы. Эти ресурсы могут включать в себя машины, используемые обычными клиентами, маршрутизаторы, терминальные серверы, персональные ЭВМ или другие устройства, которые имею доступ к Интернет. Узел может быть конечным пользователем Интернет-услуг или сервис провайдером, таким как промежуточная сеть. Однако основное внимание в этом руководстве уделено конечным пользователям Интернет-услуг. Мы предполагаем, что узел имеет возможность определять политику и процедуры для себя с согласия и при поддержке владельцев ресурсов. "Интернет" объединение тысяч сетей, связанных друг с другом посредством общего набора технических протоколов, которые делают возможным для пользователей любой сети взаимодействие друг с другом, или использование услуг каких-то удаленных сетей (FYI 4, RFC 1594). Термин "администратор" используется в отношении людей, кто несет ответственность за каждодневную работу системы и сетевых ресурсов. Это может быть несколько человек или организаций. Термин "администратор безопасности" используется в отношении людей, которые отвечают за безопасность информации и информационную технологию. В некоторых узлах эта функция может сочетаться с административной, в других, эти задачи могут решаться разными людьми. Термин "decision maker" относится к людям в узле, кто определяет или утверждает политику. Это часто (но не всегда) люди, владеющие ресурсами. 1.4. Смежные обстоятельства Рабочая группа справочника по сетевой безопасности работает над справочником по Интернет безопасности. Он представляет собой практическое руководство для помощи пользователям в защите их информации и ресурсов. 1.5. Базовый подход Это руководство написано, чтобы создать базовое руководство для разработки системы безопасности для вашего узла. Одним из общих подходов сформулирован Файтесом и др. [Fites 1989] и включает в себя следующие шаги: Определение того, что вы пытаетесь защитить. Выявление того, от чего вы пытаетесь защититься. Выявление того, откуда и какие исходят угрозы. Осуществление мер, которые должны защитить ваши данные и систему эффективным образом. Постоянное отслеживание процесса и внесение улучшений всякий раз, когда обнаруживаются слабости. Большая часть данного документа концентрируется на пункте 4, но и другие пункты не могут игнорироваться, если в вашем узле необходимо реализовать эффективный план безопасности. Общеизвестно, что цена обеспечения безопасности должна быть ниже, чем стоимость восстановления после разрушения системы. Стоимость в данном контексте должна включать в себя денежные издержки, потери доверия и репутации и, возможно, какие-то менее очевидные моменты. Без разумного осознания того, что вы должны защитить и откуда и какие исходят угрозы, следование этому правилу может быть затруднительным. 1.6. Оценка риска 1.6.1. Общее обсуждение Одной из наиболее важных причин разработки политики компьютерной безопасности является гарантия того, что усилия, потраченные, на достижение безопасности принесут выгоды, превосходящие затраты. Хотя это может показаться очевидным, возможны заблуждения относительно того, на чем следует сконцентрировать усилия. Например, существует много данных и публикаций о хакерах, атакующих компьютерные системы издали, в то время как большинство нарушений безопасности в подавляющем числе организаций возникает по вине своих сотрудников. Анализ риска включает в себя определение того, что вам надо защитить, от чего и как. Это процесс рассмотрения всех рисков, а не аранжировка этих рисков по уровню угрозы. Этот процесс включает в себя принятие эффективных в стоимостном отношении решений, связанных с защитой нужных объектов. Полный анализ рисков находится за пределами задач данного документа. [Fites 1989] и [Pfleeger 1989] рассмотрели некоторые подходы к данной теме. Однако имеется два пункта анализа риска, которые будут кратко рассмотрены в последующих секциях: Идентификация защищаемых объектов Идентификация угроз Для каждого из защищаемых объектов, основными целями безопасности являются доступность, конфиденциальность и целостность. Каждая угроза должна рассматриваться с точки зрения ее влияния на эти области. 1.6.2. Идентификация защищаемых объектов Первым шагом при анализе риска является идентификация объектов, которые нужно защитить. Некоторые вещи типа ценной частной информации, интеллектуальной собственности, различное оборудование являются очевидными, но часто упускаются из вида люди, которые используют все это. Существенным пунктом является составление списка объектов, влияющих на проблему безопасности. Список общих категорий был предложен Пфлегером [Pfleeger 1989]: (1) Оборудование: CPU, карты, клавиатуры, терминалы, рабочие станции, персональные ЭВМ, принтеры, дисковые драйвы, коммуникационные линии, терминальные серверы, маршрутизаторы. (2) Программы: тексты программ, объектные модули, утилиты, диагностические программы, операционные системы, коммуникационные программы. (3) Данные: во время исполнения, записанные в реальном времени, архивированные off-line, резервные копии, журнальные записи, базы данных, при передаче через транспортную среду. (4) Люди: пользователи, администраторы, группа поддержки оборудования. (5) Документация: на программы, оборудование, системы, локальные административные процедуры. (6) Материалы: бумага, формы, ленты, магнитные носители. 1.6.3. Идентификация угроз Когда список объектов, которые нужно защитить определен, необходимо идентифицировать угрозы. Угрозы могут быть затем рассмотрены с целью определения того, какой потенциал потерь они в себе несут. Это помогает определить, от каких угроз вам следует защищаться. Должны быть рассмотрены следующие классические угрозы. В зависимости от узла, могут существовать и специфические угрозы, которые следует идентифицировать. (1) Неавторизованный доступ к ресурсам и/или информации (2) Непреднамеренное и/или неавторизованное раскрытие информации (3) Отказ в обслуживании (Denial of service) 2. Политики безопасности В данном документе будет много ссылок на политики. Часто эти ссылки будут содержать рекомендации для специфических политик. Читателю следует использовать советы, содержащиеся в данной главе, при формировании любой политики, которые будут рекомендованы далее в данном документе. 2.1. Что такое политика безопасности и зачем она нужна? Решения, сопряженные с безопасностью, которые вы принимаете, или не можете принять в качестве администратора, определяют в заметной мере, насколько безопасна ваша сеть, какой уровень функциональности может она предложить, и насколько легко работать в этой сети. Однако вы не можете принять хорошее решение, касающиеся безопасности, без определения того, каковы ваши конечные цели. Пока вы не определите, каковы ваши цели обеспечения безопасности, вы не можете эффективно использовать любую комбинацию средств, так как вы не знаете, что проверять и какие ограничения ввести. Например, ваши цели будут, вероятно, сильно отличаться от целей поставщика продукта. Поставщики пытаются сделать конфигурирование и работу продукта как можно проще, это предполагает, что конфигурация по умолчанию будет максимально открытой (т.e., небезопасной). В то время как это облегчает инсталляцию новых продуктов, такой подход оставляет свободным доступ к этим системам и через них к другим системам. Ваши цели будут в основном определены следующими ключевыми компромиссами: (1) предлагаемые услуги против предоставляемой безопасности - каждая услуга, предлагаемая пользователям, несет в себе определенные риски безопасности. Для некоторых услуг риск перевешивает привлекательные их стороны, и администратор может принять решение их запретить, а не защищать. (2) простота использования против безопасности - Простейшая система использования позволит доступ любому пользователю и не потребует пароля; то есть, лишена какой-либо безопасности. Требование пароля делает систему менее удобной, но более безопасной. Требование одноразового пароля, формируемого аппаратно еще менее удобно для использования, но много безопаснее. (3) стоимость безопасности против риска потери - существует много различных издержек безопасности: денежные (т.e., цену покупки оборудования и программ, обеспечивающих безопасность, например, firewall и генератора одноразовых паролей), рабочие характеристики (т.e., время необходимое для шифрования и дешифрования), а также простота использования (как упомянуто выше). Существует также много уровней риска: потеря конфиденциальности (т.e., чтение информации неавторизованными лицами), потеря данных (т.e., искажение или стирание информации), и потеря услуги (например, заполнение памяти, использование вычислительных ресурсов, и отказ в доступе к сети). Каждый тип издержек должен быть оценен и сопоставлен каждым типом потерь. Ваши цели следует довести до сведения всех пользователей, оперативного персонала и менеджеров в виде набора правил безопасности, называемых "политикой безопасности". Мы используем этот термин, а не более близкое выражение "политика компьютерной безопасности", так как данная сфера включает в себя все типы информационных технологий и информацию, хранимую и обрабатываемую этой технологией. 2.1.1. Определение политики безопасности Политика безопасности является формальным объявлением правил, которым должны подчиняться лица, получившие доступ к технологии и информации организации. 2.1.2. Цели политики безопасности Главной целью политики безопасности является информирование пользователей, персонал и менеджеров об их обязанностях по защите технологии и информации. Политика должна специфицировать механизмы, через которые могут быть реализованы соответствующие требования. Другой целью является обеспечение базиса при конфигурировании и аудите компьютерных систем и сетей в соответствии с политикой. Следовательно, попытка использовать набор средств безопасности в отсутствии определенной политики безопасности является бессмысленным. Политика использования AUP (Appropriate Use Policy) может также быть частью политики безопасности. Она должна определять, что можно и чего нельзя делать с различными компонентами системы, включая типы трафика, разрешенные в сетях. AUP должна быть максимально прозрачной (заданной явно), чтобы избежать неопределенности и недоразумений. Например, AUP может перечислить какие-то запрещенные группы новостей USENET. (Заметим: AUP для некоторых узлов является приемлемой политикой использования (Acceptable Use Policy)). 2.1.3. Кого следует привлечь к формированию политики безопасности? Для того чтобы политика безопасности была адекватной и эффективной, она должна быть приемлемой и поддерживаемой на всех уровнях для сотрудников организации. Особенно важно, чтобы корпоративный менеджмент безоговорочно поддерживал политику безопасности. Ниже представлен список лиц, которые должны быть вовлечены в создание и подготовку документов по политике безопасности: (1) администратор безопасности узла (2) технический персонал информационной технологии (например, персонал вычислительного центра) (3) администраторы больших групп пользователей организации (например, коммерческие подразделения, отдел компьютерной информатики в университете и т.д.) (4) команда ликвидации инцидентов нарушения безопасности (5) представители групп пользователей, имеющие отношения к политике безопасности (6) ответственные управленцы (7) юрист (если таковой имеется) Выше в списке приведены представители многих организаций, но перечень не является исчерпывающим. Идея заключается во включении в список ключевых лиц, работающих в сети и имеющих распорядительные функции, лица, определяющие политику, технический персонал, кто знает основные разветвления политического выбора. В некоторых организациях, может быть разумным включить персонал EDP-аудита. Включение этой группы является важным, если результирующие политические заявления должны быть восприняты как можно более широким кругом лиц. Важно также упомянуть, что роль юриста может сильно варьироваться от страны к стране. 2.2. Что дает хорошая политика безопасности? Характеристиками хорошей политики безопасности являются: (1) Она должна быть реализуема через процедуры системной администрации, публикацию приемлемых руководств по использованию, или другими приемлемыми способами. (2) Она должна быть, где возможно, внедряема посредством специальных устройств и программ и через санкции, где предотвращение угроз технически невозможно. (3) Она должна ясно определять области ответственности пользователей, администраторов и менеджмента. Хорошая политика безопасности включает в себя следующие компоненты: (1) Инструкции по технологии приобретения компьютерного оборудования, которые разъясняют требования или предпочтения, связанные с безопасностью. Эта инструкция должна прилагаться к существующим рекомендациям по закупкам и закупочной политике. (2) Политику конфиденциальности, которая определяет разумные требования по обеспечению закрытости частной информации, включая мониторинг электронной почты, контроль операций, выполняемых пользователями и доступ к их файлам. (3) Политику доступа, которая определяет права доступа и привилегии с целью защиты определенных объектов от утраты или раскрытия для пользователей оперативного персонала и менеджмента. Она должна предоставить инструкции для внешнего подключения, передачи данных, устройств подключения к сети и для добавления нового программного обеспечения к системе. Она должна также специфицировать любые необходимые сообщения уведомления (например, сообщения подключения должны предоставлять предупреждения об авторизованном использовании и мониторинге канала, а не просто выдавать строку типа "Welcome"). (4) Политику аккаунтинга, которая определяет ответственность пользователей, операционного персонала и менеджмента. Она должна специфицировать возможность аудита и предоставлять инструкции обработки инцидентов (т.e., что делать и с кем связаться, если зарегистрировано вторжение). (5) Политику аутентификации, которая устанавливает эффективную политику паролей и устанавливает инструкции для удаленной аутентификации и использования аутентификационных устройств (например, одноразовых паролей и устройств их генерирующих). (6) Заявление доступности, которое устанавливает пожелания пользователей о доступности определенных ресурсов. Оно должно относиться к избыточности и восстановлению объектов, а также специфицировать часы работы и периоды остановок для обслуживания. Оно должно также включать контактную информацию для информирования о состоянии системы и об отказах. (7) Политику поддержки сети и информационных систем, которая описывает, как персоналу, отвечающему за поддержку внутренней сети и внешних каналов, разрешено использовать технологию доступа. Важный вопрос, который здесь должен быть задан, заключается в том, должен ли быть разрешен внешний доступ и как такой доступ следует контролировать. Другой областью, рассматриваемой здесь, является организация работ с субподрядными фирмами и способ ее управления. (8) Политику сообщений о нарушениях, которая указывает, какой тип нарушений (например, конфиденциальности и безопасности, внутренней или внешней) должен докладываться и кто готовит такие доклады. Доброжелательная атмосфера и возможность анонимного доклада приведет к тому, что вероятность сообщения в случае нарушения будет выше. (9) Поддерживающую информацию, которая предоставляет пользователям, персоналу и менеджменту контактные данные для каждого типа нарушений политики безопасности; инструкции о том, как обрабатывать внешние запросы об инцидентах, сопряженных с нарушением безопасности, или информацию, которая может рассматриваться как конфиденциальная или частная; и перекрестные ссылки на процедуры безопасности и сопряженную с ними данные, такие как политика компании и правительственные законы и постановления. Могут существовать регулирующие требования, которые влияют на некоторые аспекты вашей политики безопасности (например, мониторирование линий). Создатели политики безопасности должны рассматривать возможности сотрудничества в ее формировании. Как минимум, политика должна быть рассмотрена юристом. Раз ваша политика безопасности установлена, она должна быть четко доведена до сведения пользователей, персонала и менеджмента. Важной частью процесса является подписание всем персоналом регулирующего безопасность документа, которое указывает, что люди читали, поняли и согласны с требованиями политики там содержащимися. Наконец, ваша политика должна рассматриваться на регулярной основе с целью выяснения того, поддерживает ли она эффективно требования безопасности. 2.3 Политика должна быть гибкой Для того чтобы политика безопасности была жизнеспособна в долгосрочном плане, она требует большой доли гибкости, основанной на концепции архитектурной безопасности. Политика безопасности должна быть по большей части независимой от специфического оборудования и программного обеспечения. Механизмы актуализации политики должны быть четкими и понятными. Это включает процесс, вовлеченных людей и лиц, кто должен реализовать изменения. Важно также понимать, что существуют исключения для любого правила. Всякий раз, когда возможно, политика должна разъяснять, какие исключения существуют для общей политики. Например, при каких условиях системному администратору позволено просматривать файлы пользователя. Могут также существовать случаи, когда несколько пользователей имеют доступ к одному и тому же идентификатору userid. Например, в системах с пользователем root, несколько системных администраторов могут знать пароль и использовать аккаунт root. Другое соображение называется "Garbage Truck Syndrome" (синдром мусоровоза). Это относится к тому, что может произойти с сайтом, если ключевое лицо неожиданно становится недоступным для выполнения его/ее рабочих функций (например, неожиданно заболело или покинуло компанию). В то время как максимальная безопасность требует минимального распространения информации, риск потери критической информации увеличивается, когда данные не носят распределенного характера. Важно определить, какой баланс является приемлемым для вашего узла. 3. Архитектура 3.1. Объективные характеристики 3.1.1. Полностью определенные планы безопасности Все узлы должны определить всеобъемлющий план обеспечения безопасности. Этот план должен охватывать более высокий уровень, чем политики, обсужденные в главе 2, и он должен рассматриваться в качестве базы для широкого перечня инструкций, которым должны соответствовать специфические виды политики. Важно иметь этот перечень в таком виде, чтобы индивидуальные политики могли быть совместимы с общей архитектурой безопасности узла. Например, жесткая политика в отношении к доступу в Интернет и слабые ограничения на использование модемов не согласуются с общей философией жестких ограничений на безопасность внешнего доступа. План безопасности должен определять: список предоставляемых сетевых услуг; области организации, которые эти услуги предоставляют; кто будет иметь доступ к этим услугам; как осуществляется доступ; кто администрирует эти услуги и т.д. План должен рассматривать то, какова будет реакция на инцидент. Глава 5 содержит всестороннее обсуждение этой темы, но важно определить для каждого узла классы инцидентов и соответствующие меры противодействия. Например, узлы с сетевым экраном устанавливают порог на число попыток прохода, прежде чем будет запущен отклик? Должны быть определены уровни эскалации, как для атак, так и для откликов. Узлы без сетевого экрана должны определить, является ли инцидентом одиночная попытка соединиться с ЭВМ? Что делать с систематическим сканированием системы? Для узлов, подключенных к Интернет, стремительно расширяющаяся среда Интернет в отношении числа инцидентов безопасности может замаскировать (потенциально) более серьезные внутренние проблемы безопасности. Аналогично, компании, которые никогда не подключались к Интернет, могут иметь сильные, хорошо определенные внутренние политики, но терпят неудачу в формировании адекватной политики внешних подключений. 3.1.2. Разделение услуг Существует много услуг, которые узел может захотеть предоставить своим пользователям, некоторые из которых могут быть внешними. Существует много соображений безопасности, требующих изоляции услуг в пределах выделенных ЭВМ. Услуги, которые узел может предоставить, в большинстве случаев, имеют различные уровни необходимости доступа и модели доверия. Услуги, которые важны с точки зрения безопасности или беспрепятственной работы узла, лучше разместить на специально выделенной ЭВМ с весьма ограниченным доступом (смотри раздел 3.1.3 модель "запрет всего"), а не на машине, предоставляющей услугу (или услуги), традиционно являющейся менее безопасной, или требующей более широкого доступа пользователей, которые могут спровоцировать подрыв безопасности. Очень важно также уметь различать ЭВМ, которые работают с разными моделями доверия (например, все ЭВМ внутри контура firewall и любая ЭВМ незащищенной сети). Некоторые услуги, которые следует учитывать, как потенциально изолируемые, рассмотрены в разделе 3.2.3. Важно помнить, что безопасность настолько надежна, насколько надежен самый слабый участок цепочки. Несколько наиболее известных проникновений за последние годы использовали уязвимость систем электронной почты. Атакеры не пытались украсть почтовые сообщения, они использовали уязвимость этой услуги для получения доступа к другим системам. Если возможно, каждая услуга должна работать на отдельной машине, чьей единственной заботой является предоставление специфицированных услуг. Это помогает изолировать атакера и ограничить потенциальный ущерб. 3.1.3. Запретить все / разрешить все Существует две диаметрально противоположные базовые философии, которые могут быть приняты, когда определяется план безопасности. Обе альтернативы являются приемлемыми моделями, и выбор между ними зависит от узла и его требований безопасности. Первым шагом является отключение всех сервисов, а затем селективное открытие услуг по мере необходимости. Это может быть сделано на уровне ЭВМ или сети, как удобнее. Данная модель, которая называется здесь моделью "запрет всего", является более безопасной, чем другая модель, описанная в следующем параграфе. Для успешного конфигурирования модели "запрет всего" требуется больше работы и понимания функционирования услуг. Допуск только известных услуг обеспечивает лучший анализ конкретных услуг/протоколов и формирование механизма безопасности, соответствующего требования узла. Другая модель, которая называется здесь моделью "разрешить все", реализуется много проще, но менее безопасна, чем модель "запрет всего". Просто включаются все сервисы, обычно на уровне по умолчанию (ЭВМ), и на границе сети допускаются все протоколы на уровне маршрутизатора. Так как уязвимости безопасности оказываются открыты, они перекрываются на уровне ЭВМ или сети. Каждая из этих моделей может быть использована в равной пропорции в каждом узле, в зависимости от функциональных требований, административного управления, политики узла и т.д.. Например, политикой при конфигурировании рабочих станций может быть использование модели "разрешить все", в то время как для информационных серверов может быть применена модель "запрет всего". Аналогично, политика "разрешить все" может быть принята для трафика между сетями внутри локальной сети, а "запрет всего" - при обмене между узлом и Интернет. Следует быть осторожным, смешивая разные философии, как в выше приведенном примере. Многие узлы принимают теорию жесткой "уплотненной" оболочки и мягкой "рыхлой" сердцевины. Они готовы платить за безопасность своего внешнего трафика и требуют строгих мер безопасности, но не хотят или не могут обеспечить подобные меры внутри. 3.1.4. Идентификация реальных потребностей в услугах Существует большое разнообразие услуг, которые могут быть предоставлены, как локально, так и через Интернет. Управление безопасностью является во многих отношениях, управлением доступом к внутренним услугам и управлением тем, как внутренние пользователи осуществляют доступ к информации внешних узлов. Услуги имеют тенденцию распространяться подобно волнам по Интернет. За годы во многих узлах были установлены анонимные FTP-серверы, серверы gopher, серверы wais, WWW-серверы и т.д., так как они становились популярными, но не были особенно нужны во всех узлах. Оцените все новые услуги скептически и определите, нужны ли они на самом деле или являются лишь модной прихотью Интернет. Следует учитывать, что в случае предоставлении нескольких услуг сложность обеспечения безопасности может расти экспоненциально. Фильтрующие маршрутизаторы для поддержания новых протоколов должны быть модифицированы. Некоторые протоколы в действительности трудно фильтровать безопасным образом (например, услуги RPC и UDP), таким образом, предоставляя больше окон уязвимости внутренней сети. Услуги, предоставляемые на той же машине, могут взаимодействовать катастрофическим образом. Например, разрешение анонимного FTP на некоторой машине, которая выполняет функцию WWW-сервера, может позволить атакеру записать в область анонимного FTP некоторый файл, после чего запустить его посредством HTTP-сервера. 3.2. Конфигурация сети и услуг 3.2.1. Защита инфраструктуры Многие сетевые администраторы готовы идти на большие издержки, чтобы защитить ЭВМ их сети. Немногие администраторы делают что-либо, чтобы защитить сами сети. К этому есть определенные предпосылки. Например, ЭВМ защитить много легче чем сеть. Кроме того, атакеров скорее интересуют конкретные машины, а нанесение ущерба сети в их планы не входит. Тем не менее, существуют причины защиты сетей. Например, атакер может перенаправить сетевой трафик через ЭВМ вне сети, чтобы просмотреть интересующие его данные (например, перехватить пароли). Инфраструктура включает в себя сетевое управление (например, SNMP), услуги (например, DNS, NFS, NTP, WWW) и безопасность (т.e., аутентификация пользователей и ограничения доступа). Инфраструктура также нуждается в защите от человеческих ошибок. Когда администратор неверно конфигурирует ЭВМ, сервис, предоставляемый машиной, может деградировать. Это существенно только для пользователей этой ЭВМ, если только эта машине не является первичным сервером, число пострадавших пользователей при этом ограничено. Однако если маршрутизатор некорректно сконфигурирован, все пользователи, кто нуждается в доступе к сети, пострадают. Очевидно, что число пользователей несравненно большее, чем число людей, зависящих от услуг одной ЭВМ. 3.2.2. Защита сети Существует несколько проблем, которые актуальны для сетей. Классической проблемой является атака "denial of service" (отказ в обслуживании). В этом случае, сеть попадает в состояние, при котором она не может более передавать данные пользователя. Существует два способа реализации такого состояния: путем атаки маршрутизаторов и с помощью перегрузки сети избыточным трафиком. Заметим, что термин маршрутизатор в этом разделе используется как активное сетевое устройство самого широкого класса, сюда могут относиться сетевые экраны (firewall), прокси-серверы, и т.д. Атака на маршрутизатор заключается в блокировке им передачи пакетов или в переадресации их некорректным образом. В первом случае может иметь место не верная конфигурация, произвольная модификация маршрутной таблицы, или "атака перегрузки" (т.e., маршрутизатор забрасывается немаршрутизуемыми пакетами, что вызывает деградацию его рабочих характеристик). Атака перегрузки на сеть аналогична подобной атаке на маршрутизатор, за исключением того, что пакеты являются обычно широковещательными. Идеальной атакой перегрузки являлась бы такая, при которой посылка одного пакета, использующего известную уязвимость, вызывала посылку лавины пакетов. Другой классической проблемой является фальсификация (spoofing). В этом случае маршрутизатору посылается запрос произвольной модификации маршрутов, заставляя его послать одному или нескольким маршрутизаторам данные, искажающие маршрутизацию пакетов. Это отличается от атаки отказа обслуживания только целью модификации маршрута. При отказе обслуживания, целью является выведение из строя маршрутизатора; что будет быстро замечено пользователями сети. При фальсификации, ложный путь вынудит пакеты двигаться к ЭВМ, где атакер мониторирует передаваемую информацию. Эти пакеты переадресуются затем по их правильному месту назначения. Однако атакер может менять или не менять при этом содержимое пакетов. Решением большинства этих проблем является предотвращение посылки пакетов модификации маршрутов протоколами маршрутизации (например, RIP-2, OSPF). Существует три уровня защиты: пароль с открытым текстом, криптографическая контрольная сумма и шифрование. Пароли предоставляют минимальную защиту от атакеров, которые не имеют непосредственного физического доступа к сети. Пароли также предлагают некоторую защиту от некорректного конфигурирования маршрутизаторов. Преимуществом паролей является малая избыточность в отношении полосы и ресурсов CPU. Контрольные суммы защищают от присылки ложных пакетов, даже в случае, когда атакер имеет физический доступ к сети. В сочетании с номером по порядку или другим уникальным идентификатором контрольная сумма может защитить также от атак "откликов", когда атакером или “сошедшим с ума” маршрутизатором повторно присылается старое (но корректное) обновление маршрута. Большая безопасность достигается пересылкой закодированной маршрутной информации. Это мешает атакеру определить топологию сети. Недостатком шифрования является избыточность, связанная с обработкой зашифрованных сообщений. RIP-2 (RFC 1723) и OSPF (RFC 1583) оба поддерживают пароли с открытым текстом в своей основной спецификации. Кроме того, существует расширения этих базовых протоколов, поддерживающие MD5-шифрование. К сожалению, не существует приемлемой защиты от атак перегрузки (flooding), или некорректного поведения ЭВМ или маршрутизатора, перегружающих сеть. К счастью, этот тип атак является очевидным и по этой причине хорошо диагностируемым и устраняемым. 3.2.3. Защита услуг Существует много типов услуг и каждая из них имеет свой уровень требований безопасности. Эти требования будут варьироваться в зависимости от назначения услуги. Например, услуга, которая предназначена для применения исключительно внутри узла (например, NFS) может требовать механизмов защиты, отличных от используемых в случае внешних приложений. Может быть достаточно защитить внутренний сервер от внешнего. Однако, WWW-сервер, который должен быть доступен из любой точки Интернет, требует встроенной защиты. То есть, сервис/протокол/сервер должны обеспечивать любую безопасность, необходимую для предотвращения неавторизованного доступа и модификации базы данных Web. Внутренние услуги (т.e., услуги, используемые в пределах узла) и внешние услуги (т.e., услуги, преднамеренно сделанные доступными для пользователей за пределами узла) будут, вообще говоря, иметь требования безопасности, которые существенно отличаются. Следовательно, разумно ограничить внутренние услуги набором ЭВМ, подключенных к серверу, а внешние услуги должны быть доступны на других серверах. То есть, внутренние и внешние серверы не должны размещаться на одном и том же компьютере. Фактически, многие узлы имеют один набор субсетей (или даже сетей), которые доступны извне, и другой набор, который доступен изнутри. Эти две области соединяются через firewall. Должно уделяться большое внимание для обеспечения корректной работы такого firewall. Усиливается интерес к использованию Интранет для соединения различных частей организации (например, отделения компании). В то время как данный документ делает четкое различие между внешними и внутренними частями (общедоступные и частные), узлы, использующие Интранет, должны позаботиться о рассмотрении трех зон и предпринять соответствующие действия, проектируя сеть и предоставляя услуги. Услуга, предлагаемая в Интранет, не является ни общедоступной, ни в полной мере частной. Следовательно, услуга требует своей собственной системы поддержки, отделенной от внешних и внутренних услуг и сетей. Один вид внешних услуг достоин специального рассмотрения, это анонимный или гостевой доступ. Это может быть анонимное FTP или гостевой (не аутентифицированный) login. Особенно важно гарантировать, чтобы анонимные серверы FTP и гостевые аккаунты были тщательно изолированы от любых ЭВМ и файловых систем, куда не следует пускать внешних пользователей. Другой областью специального внимания должен быть анонимный доступ с возможностью записи. Узел может быть юридически ответственен за общедоступную информацию, поэтому рекомендуется мониторировать данные, заносимые анонимными пользователями. Теперь мы рассмотрим некоторые наиболее популярные услуги: службу имен, службу паролей/ключей, службу аутентификации, электронную почту, WWW, пересылку файлов и NFS. Так как эти услуги наиболее часто используются, они являются объектами атак. Успешная атака на одну из услуг может привести к катастрофе всей системы в целом. 3.2.3.1. Серверы имен (DNS и NIS(+)) Интернет использует DNS (Domain Name System) для определения адресов ЭВМ и сетевых имен. Службы NIS (Network Information Service) и NIS+ не используются в глобальном Интернет, но являются причиной тех же рисков, что и DNS-сервер. Преобразование имени в адрес является критическим в отношении безопасного функционирования сети. Атакер, который может успешно управлять DNS-сервером, сможет перенаправить трафик, чтобы обойти защиту. Например, трафик для просмотра может быть перенаправлен на скомпрометированную систему; или, пользователи могут быть введены в заблуждения и они раскроют свои аутентификационные параметры. Организация должна создавать защищенные узлы, работающие в качестве вторичных серверов имен, и защитить свои DNS серверы от DoS-атак, использующих фильтрующие маршрутизаторы. Традиционно DNS не имел средств обеспечения безопасности. В частности, информация, присылаемая в ответ на запрос, не может проверяться на предмет модификации и не может осуществляться верификация отправителя. Проделана работа по внедрению цифровых подписей в протокол, который в случае реализации, криптографически обеспечит целостность и верификацию информации (смотри RFC 2065). 3.2.3.2. Серверы ключей и паролей (NIS(+) и KDC) Серверы паролей и ключей защищают жизненно важную информацию (т.e., пароли и ключи) с помощью алгоритмов шифрования. Однако даже пароли с однопроходным шифрованием могут быть раскрыты (здесь зашифрованные слова сравниваются с образцами, которые хранятся в памяти). Следовательно, необходимо гарантировать, что эти серверы недоступны для машин, которые не должны использовать этот вид услуги. 3.2.3.3. Серверы аутентификации и прокси (SOCKS, FWTK) Прокси сервер предоставляет ряд улучшений безопасности. Он позволяет узлам концентрировать услуги посредством специально выделенной ЭВМ, что допускает мониторирование, сокрытие внутренней структуры и т.д. Такая скрытность услуг является привлекательной мишенью для потенциального атакера. Тип защиты, необходимой для прокси-сервера, сильно зависит от используемого прокси протокола и проксируемых услуг. Общим правилом ограничения доступа является разрешение доступа только машинам, которые действительно нуждаются в услугах. Причем даже для них разрешается доступ только к определенным видам услуг. 3.2.3.4. Электронная почта Системы электронной почты (e-mail) в течение долгого времени служили источником вторжений, так как почтовые протоколы являются старейшими и наиболее широко используемыми услугами. Кроме того, согласно своей природе, почтовый сервер требует доступа из внешнего мира. Большинство почтовых серверов позволяют доступ от любого субъекта сети. Почтовый сервер обычно состоит из двух частей: агент приема/передачи и агент обработки. Так как почта доставляется всем пользователям и обычно является конфиденциальной, агент обработки требует системных (root) привилегий при доставке. Большинство реализаций e-mail-сервера выполняют обе эти функции, что означает предоставление системных привилегий и принимающему агенту. Это открывает несколько окон уязвимости. Существуют некоторые реализации, которые позволяют разделение этих двух агентов. Такие реализации считаются более безопасными, но все еще нуждаются в тщательной инсталляции, чтобы избежать дополнительных проблем безопасности. 3.2.3.5. Всемирная паутина (WWW) Популярность Web растет экспоненциально, так как эта услуга проста в использовании и эффективна в сфере информационных услуг. Большинство WWW-серверов воспринимает команды и действует согласно инструкциям клиента, предоставляя доступ к своим ресурсам. Наиболее общим примером приема запроса удаленного пользователя и передачи полученной информации программе, работающей на сервере для обработки запроса. Некоторые из этих программ написаны без учета требований безопасности и могут создать угрозы проникновения. Если Web-сервер доступен для Интернет-сообщества, особенно важно, чтобы конфиденциальная информация не размещалась на том же компьютере, что и сервер. Фактически, рекомендуется, чтобы сервер имел выделенную ЭВМ, которой "не доверяют" остальные машины внутренней сети. Многие узлы хотят совмещать FTP-услуги с WWW-сервисом. Но это допустимо только для анонимных ftp-серверов, которые лишь предоставляют информацию (ftp-get). Анонимные ftp put в комбинации с WWW могут быть опасны (например, они могут привести к модификациям информации, предоставляемой вашим узлом). Соображения безопасности для каждого из видов сервиса должны быть разными. 3.2.3.6. Пересылка файлов (FTP, TFTP) FTP и TFTP позволяют пользователям получить и послать файлы в режиме точка-точка. Однако FTP требует аутентификации, в то время как TFTP нет. По этой причине TFTP следует по возможности избегать. Неправильно сконфигурированные FTP-серверы могут позволить атакеру копировать, заменять и удалять файлы по своему усмотрению, так что очень важно конфигурировать этот вид услуг корректно. Доступ к шифрованным паролям и частным данным, и введение троянских коней являются лишь небольшой долей возможных неприятностей, которые могут случиться при неправильной конфигурации. FTP-серверы должны размещаться на своих собственных машинах. Некоторые узлы помещают FTP и Web-серверы на одной ЭВМ, так как оба протокола имеют схожие требования безопасности. Однако практика этого не рекомендует, особенно когда FTP-сервис позволяет записывать файлы (смотри раздел WWW выше). Как было упомянуто в начальных параграфах раздела 3.2.3, услуги, предоставляемые внутренним пользователям узла не должны соседствовать с услугами, предлагаемыми для внешних клиентов. Каждый вид услуг должен иметь свою ЭВМ.TFTP не поддерживает тот же список функций, что и FTP, и не имеет вообще никакой защиты. Эта услуга должна рассматриваться исключительно для внутреннего использования, и она должна конфигурироваться так, чтобы доступ был возможен к ограниченному и предопределенному набору файлов. Вероятно, большинство применений TFTP сопряжено с загрузкой конфигурационных файлов в маршрутизатор. TFTP должен размещаться на своей собственной ЭВМ, и не должен устанавливаться на машины, поддерживающие внешнийFTP или Web-доступ. 3.2.3.7. NFS Сетевая файловая система (Network File Service) позволяет ЭВМ совместно использовать диски. NFS могут использовать бездисковые ЭВМ, которые зависят от дисковых серверов для любых операций записи и чтения. К сожалению, NFS не имеет встроенных средств защиты. Следовательно необходимо, чтобы NFS-сервер был доступен только для тех ЭВМ, которые должны пользоваться его услугами. Это достигается путем спецификации того, как и какие ЭВМ обслуживаются файловой системой (например, только для чтения, чтение-запись, и т.д.). Файловые системы не должны транспортироваться каким-либо ЭВМ за пределами локальной сети, так как это потребует, чтобы NFS-сервис был доступен извне. Идеально, внешний доступ к NFS-услугам должен быть перекрыт с помощью firewall. 3.2.4. Защищая защиту Удивительно, как часто узлы не обращают внимания на совершенно очевидные слабости в сфере безопасности, оставляя сам сервер безопасности открытым для атак. Основываясь на обсужденных выше соображениях, должно быть ясно, что: сервер безопасности не должен быть доступен извне; он должен предлагать минимальный доступ, за исключением функции аутентификации в отношении внутренних пользователей; и не должен делить машину с другими серверами. Далее, все операции доступа к узлу, включая доступ к самому этому сервису, должен регистрироваться в специальных файлах, чтобы обеспечить аудит в случае обнаружения успешных атак. 3.3. Сетевые экраны (Firewalls) Одной из широко используемых мер безопасности является применение сетевых экранов - firewall. Сетевые экраны считаются панацеей от многих, если не от всех проблем безопасности в Интернет. Но это не так. Сетевые экраны являются лишь инструментом системы безопасности. Они предоставляют определенный уровень защиты и являются вообще средством реализации политики безопасности на сетевом уровне. Уровень безопасности, который предоставляет сетевой экран, может варьироваться в зависимости от требований безопасности конкретной машины. Существует традиционный компромисс между безопасностью, простотой использования, стоимостью, сложностью и т.д. Сетевой экран является одним из нескольких механизмов, используемых для управления и наблюдения за доступом к и из сети с целью ее защиты. Сетевой экран действует как шлюз, через который проходит весь входной и выходной трафик защищенной сети. Сетевые экраны помогают установить ограничения на число и тип коммуникаций, которые осуществляются между защищенной сетью и прочими сетями (например, Интернет или другой частью сети узла). Сетевой экран является способом построения стены между одной частью сети, например, внутренней сетью компании, и глобальным Интернет. Уникальной чертой этой стены является наличие дверей, через которые при тщательном контроле проходит некоторый трафик. Трудной частью такой системы является установление критериев того, какие пакеты разрешить, а каким запретить проход через эти двери. В книгах, написанных о сетевых экранах, используется разная терминология для описания различных форм сетевых экранов. Это может сбивать системных администраторов, которые не знакомы с сетевыми экранами. Следует здесь заметить, что не существует стандартной терминологии для описания сетевых экранов. Сетевые экраны не обязательно представляют собой отдельную машину. Сетевые экраны скорее представляют собой комбинацию маршрутизаторов, сетевых сегментов, и рабочих станций. Следовательно, в рамках данного обсуждения, термин "сетевой экран" предполагает наличие более одного физического устройства, фильтрующих маршрутизаторов и прокси-серверов. Фильтрующие маршрутизаторы представляют собой простейший компонент сетевого экрана. Маршрутизатор передает данные в обоих направлениях между двумя (или более) разными сетями. "Нормальный" маршрутизатор принимает пакет из сети A и "переадресует" его к месту назначения в сети B. Фильтрующий маршрутизатор делает то же самое, но решает не только как маршрутизовать пакет, но также следует ли этот пакет посылать куда-либо вообще. Это делается путем установки ряда фильтров, с помощью которых маршрутизатор решает, что делать конкретно с данным пакетом. При подготовке маршрутизатора для фильтрации пакетов, важны следующие критерии политики отбора: IP-адреса отправителя и получателя, номера TCP-портов отправителя и получателя, состояние бита TCP "ack", номера UDP-портов отправителя и получателя, и направление передачи пакетов (т.e., A->B или B->A). Другой информацией, необходимой для формирования схемы безопасной фильтрации, является, меняет ли маршрутизатор порядок инструкций фильтрации (с целью оптимизации фильтров, это может иногда изменить значение и привести к непреднамеренному доступу), и можно ли использовать фильтры для входящих и выходящих пакетов на каждом из интерфейсов. Если маршрутизатор фильтрует только выходные пакеты, тогда он является внешним по отношению своих фильтров и может быть более уязвим для атак. Кроме уязвимости маршрутизатора, это различие между фильтрами, используемыми для входных и выходных пакетов, является особенно важным для маршрутизаторов с более чем 2 интерфейсами. Другими важным моментом является возможность создавать фильтры на основе опций IP-заголовка и состояния фрагментов пакета. Формирование хорошего фильтра может быть очень трудным и требовать хорошего понимания типа услуг (протоколов), которые будут фильтроваться. Для лучшей безопасности, фильтры обычно ограничивают доступ между двумя связанными сетями к лишь одной ЭВМ. Можно получить доступ к другой сети только через эту защищенную машину. Так как только эта ЭВМ, а не несколько сот машин, может быть атакована, легче поддержать определенный уровень безопасности, так как именно эта машина может быть защищена особенно тщательно. Чтобы сделать доступными через этот сетевой экран ресурсы для легальных пользователей услуги должны переадресовываться соответствующим серверам через эту защищенную машину. Некоторые серверы имеют встроенную переадресацию (например, DNS-серверы или SMTP-серверы), для других услуг (например, Telnet, FTP, и т.д.) могут использоваться прокси серверы, чтобы обеспечить доступ к ресурсам безопасным способом через firewall. Прокси сервер является средством переадресации прикладных услуг через одну машину. Существует обычно одна машина (защищенная ЭВМ), которая действует в качестве прокси сервера для широкого списка протоколов (Telnet, SMTP, FTP, HTTP, и т.д.), но могут быть индивидуальные машины для некоторых видов услуг. Вместо непосредственного соединения с внешним сервером, клиент подключается к прокси серверу, который в свою очередь инициирует соединение с запрашиваемым внешним сервером. В зависимости от используемого прокси сервера можно конфигурировать внутренних клиентов так, чтобы они осуществляли это перенаправление автоматически, без информирования пользователя, другие могут требовать, чтобы пользователь сам подсоединялся к прокси серверу и затем инициировал подключение в рамках специального формата. Применение прокси сервера предоставляет существенные преимущества в обеспечении безопасности. Имеется возможность добавления списков доступа для протоколов, требующие от пользователей или систем обеспечения определенного уровня аутентификации прежде чем доступ будет предоставлен. Могут быть запрограммированы продвинутые прокси серверы, иногда называемые ALG (Application Layer Gateways), которые ориентированы на определенные протоколы. Например, ALG для FTP может отличать команду "put" от "get"; организация может пожелать разрешить пользователям выполнять "get" для файлов из Интернет, но запретить "put" для локальных файлов на удаленном сервере. Напротив, фильтрующий маршрутизатор может блокировать или нет FTP-доступ, но не может реализовывать частичные запреты. Прокси серверы могут также конфигурироваться для шифрования потоков данных на основе разнообразных параметров. Организация может использовать эту особенность, чтобы разрешить криптографические соединения между двумя узлами, один из которых размещен в Интернет. Сетевые экраны обычно рассматриваются как средство блокировки доступа для атакеров, но они часто используются в качестве способа доступа легальных пользователей к узлу. Существует много примеров, когда легальному пользователю может быть нужно получать регулярно доступ к базовой странице во время презентаций, конференций и т.д. Доступ к Интернет бывает часто реализован через ненадежную машину или сеть. Правильно сконфигурированный прокси сервер может допускать правильных пользователей в узел, блокируя доступ всех остальных. В настоящее время наилучшим вариантом сетевого экрана считается комбинация двух экранирующих маршрутизаторов и одного или более прокси серверов в сети между маршрутизаторами. Такая схема позволяет внешнему маршрутизатору блокировать любые попытки использования нижележащего IP-уровня для разрушения безопасности (IP-фальсификация, маршрутизация отправителя, фрагменты пакетов), в то же время прокси сервер защищает окна уязвимости на уровне верхних протоколов. Целью внутреннего маршрутизатора является блокировка всего трафика кроме направленного на вход прокси сервера. Если реализована эта схема, может быть обеспечен высокий уровень безопасности. Большинство сетевых экранов предоставляют систему журналов, которые могут настраиваться, чтобы сделать администрирование безопасности сети более удобным. Система мониторинга может быть централизована, а система сконфигурирована так, чтобы посылать предупреждения при возникновении ненормальной ситуации. Важно регулярно просматривать журнальные файлы при малейшем признаке вторжения или попытки взлома. Так как некоторые атакеры будут пытаться скрыть свои следы путем редактирования журнальных файлов, желательно защитить эти файлы. Существует много способов, включая: драйвы WORM (write once, read many), бумажные журналы и централизованные журнальные файлы, организованные через утилиту "syslog". Еще одним методом является использование "фальшивого" последовательного принтера, где последовательный порт соединен с изолированной машиной, где хранятся журнальные файлы. Существуют сетевые экраны в широком диапазоне качества и мощности. Цена коммерческого варианта начинается примерно с $10,000US и достигает $250,000US. "Самодельные" сетевые экраны могут быть построены за меньшую сумму. Следует учитывать, что правильная конфигурация сетевого экрана (коммерческого или самодельного) требует определенного мастерства и знания TCP/IP. Оба типа требуют регулярного обслуживания, установки пакетов обновления и корректировки программ и непрерывного контроля. При оценке бюджета сетевого экрана, эти дополнительные издержки должны также учитываться наряду с аппаратной частью сетевого экрана. Сетевые экраны могут оказать помощь при обеспечении безопасности узла, они защищают от большого числа атак. Но важно иметь в виду, что они являются лишь частью решения. Они не могут защитить ваш узел от всех типов атак. 4. Процедуры и услуги безопасности 4.1. Аутентификация В течение многих лет в качестве стандарта применялся метод аутентификации пользователей с помощью многократно используемых паролей. Первоначально, эти пароли использовались клиентами на терминалах для идентификации на центральной ЭВМ. В то время не было сетей (внутри или вне), так что риск раскрытия пароля с открытым текстом был минимальным. Сегодня системы соединяются друг с другом через локальные сети, а эти локальные сети соединяются между собой и с Интернет. Пользователи входят в систему со всего мира; их многократно используемые пароли часто передаются через одни и те же сети открытым текстом, удобным для перехвата по пути кем угодно. И действительно, координационный центр CERT и другие группы реагирования регистрируют огромное число инцидентов, связанных с использование программ типа sniffer, которые перехватывают пароли с открытым текстом. С появлением новых технологий, типа однократных паролей (например, S/Key), PGP, и устройств символьной аутентификации, базирующейся на признаках (token), люди стали использовать паролеподобные строки в качестве секретных признаков. 4.1.1. Одноразовые пароли Как отмечалось выше, в существующем сегодня сетевом окружении рекомендуется, чтобы узлы, заинтересованные в безопасности и целостности своих систем и сетей, рассмотрели возможность отхода от стандарта повторно используемых паролей. Зарегистрировано много инцидентов с программами типа троянский конь или sniffer. Эти программы перехватывали аутентификационные параметры - имя_ЭВМ/аккаунт имя/пароль. Атакеры могут использовать перехваченную информацию для последующего доступа к этим машинам и аккоунтам. Это возможно, так как 1) пароль используется снова и снова, и 2) пароль передается через сеть открытым текстом. Было разработано несколько методик, которые ориентированы на эту проблему. Среди этих методик - техника отклика на вызов (challenge-response), которая предоставляет пароль, используемый однократно (обычно называемый одноразовым паролем). Существует много продуктов, которые узлы могут использовать. Решение использовать продукт находится в области ответственности конкретной организации пользователей. 4.1.2. Kerberos Kerberos является распределенной сетевой системой безопасности, которая осуществляет аутентификацию в незащищенных сетях. При запросе от приложения целостность и шифрование могут быть также обеспечены. Система Kerberos была первоначально разработана в Массачусетском Технологическом институте (MIT) в середине 80-х. Существуют две базовые версии системы Kerberos 4 и 5, которые несовместимы для практических целей. Kerberos основан на базе данных симметричных ключей, используемой центром раздачи ключей KDC (key distribution center), который известен как сервер Kerberos. Пользователю услуги (называемому "принципалом") KDC предоставляет электронный "билет". Такой билет используется для аутентификации принципалов между собой. Все билеты включают в себя временные метки, которые ограничивают время действия билета. Следовательно, клиент и сервер Kerberos должен иметь безопасные часы, и быть способными поддерживать необходимую точность времени. Практической особенностью Kerberos является его интеграция на прикладном уровне. Типовые приложения вроде FTP, telnet, POP и NFS интегрированы с системой Kerberos. Существует множество реализаций с разным уровнем интеграции. По вопросам, касающимся Kerberos рекомендуется обращаться по адресу http://www.ov.com/misc/kr-faq.html. 4.1.3. Выбор и защита секретных ключей и PIN При выборе секретной строки следует проявлять осторожность. Как и в случае паролей, секретные строки должны быть устойчивы против грубого подбора. То есть, они не должны быть отдельными словами, на каком-либо языке, или общими, промышленными или какими-либо иными акронимами. В идеале, они должны быть достаточно длинными, содержать строчные и прописные буквы, числа и другие символы. После того как секретная строка выбрана, следует заботиться о ее защите. Некоторые из них используются в качестве контрольных кодов в специальном оборудовании (например, кодовых карт) и тогда не нужно их записывать или хранить там же, где находится проверяющее их устройство. При использовании криптографических продуктов, вроде PGP, позаботьтесь о выборе ключа достаточной длины и примите меры, чтобы ваши пользователи поступали также. По мере технического прогресса минимальный размер ключа растет. Примите меры, чтобы ваш узел отслеживал новейшие достижения технологии, так чтобы вы могли быть уверены, что на используемые вами криптографические средства можно положиться. 4.1.4. Надежность пароля Хотя необходимость отказа от повторно используемых паролей не может быть переоценена, некоторые организации используют эту технику до сих пор. Для таких организаций мы предлагаем некоторые советы по выбору и поддержанию традиционных паролей. Но помните, ни одна из этих мер не сможет противостоять вскрытию с помощью программ типа sniffer. (1) Важность надежных паролей. Во многих (если не во всех) случаях проникновения в систему, атакеру нужно получить доступ к аккаунту системы. Единственным способом выполнить это является подбор пароля легального пользователя. Это часто осуществляется с помощью автоматической программы вскрытия паролей, которая использует очень большой словарь. Единственной защитой от вскрытия пароля таким способом является тщательный выбор пароля, который трудно подобрать (т.e., комбинации чисел, букв и знаков препинания). Пароли должны быть настолько длинны, насколько способна поддержать система и могут выдержать пользователи. (2) Изменение паролей по умолчанию. Многие операционные системы и прикладные программы устанавливаются с паролями и аккаунтами по умолчанию. Они должны быть изменены немедленно на что-то трудно угадываемое. (3) Ограничение доступа к файлу паролей. В частности, узел хочет защитить часть файла с шифрованными паролями так, чтобы атакер не имел туда доступа. Эффективной методикой является использование теневых паролей, где поле паролей стандартного файла содержит пустышки или фальшивые пароли. Файл, содержащий легальные пароли, защищен и находится где-то в другом месте. (4) Старение паролей. Когда и как завершается действие пароля является предметом дискуссии среди специалистов в области безопасности. Считается общепринятым, что пароль прекращает работать, когда аккаунт выходит из употребления, но активно обсуждается, следует ли вынуждать пользователя менять хороший пароль, который активно используется. Аргументы в пользу изменения пароля относятся к предотвращению использования вскрытого аккаунта. Однако оппоненты возражают, что частая смена паролей заставляет пользователей записывать их в легко доступных местах (например, непосредственно на терминале), или выбирать очень простые пароли, которые легко угадать. Следует заметить, что атакер использует, вероятно, вскрытый пароль скорее рано, чем поздно, с учетом этого замена старого пароля предоставит несущественную защиту. В то время как нет определенного ответа на эту дилемму, политика паролей должна непосредственно определять это и задавать то, как часто пользователь должен менять пароль. Конечно, ежегодная замена паролей обычно не составляет труда для пользователей, и нам следует рассмотреть такого рода требование. Рекомендуется, чтобы пароли менялись, по крайней мере, всякий раз, когда скомпрометирован привилегированный аккаунт, произошло критическое изменение персонала (особенно, если это администратор!), или когда аккаунт скомпрометирован. (5) Блокировка пароля/аккаунта. Некоторые узлы считают полезным аннулировать аккаунт, после заданного числа неудачных попыток аутентификации. Если ваш узел решает использовать этот механизм, рекомендуется, чтобы механизм не "раскрывал" себя. При неудачной аутентификации даже при вводе правильного пароля сообщение должно уведомлять лишь о неудаче, не раскрывая ее причины. Реализация этого механизма потребует, чтобы легальные пользователи связались со своим системным администратором для реактивации аккаунта. (6) Немного о демоне finger. По умолчанию, демон finger предоставляет достаточно большой объем системной и пользовательской информации. Например, он может отобразить список всех пользователей, использующих в данное время систему, или все содержимое специального файла пользователя (plan file). Эта информация может использоваться атакером для идентификации имени пользователя и угадывания его пароля. Рекомендуется, чтобы узлы модифицировали finger, чтобы ограничить выдаваемую информацию. 4.2. Конфиденциальность Всегда будет существовать информация, которую ваш узел хотел бы защитить от несанкционированного доступа. Операционные системы часто имеют встроенные механизмы защиты файлов, которые позволяют администратору управлять тем, кто в системе может иметь к ним доступ, или "читать" содержимое файла. Более строгим путем обеспечения конфиденциальности является шифрование. Шифрование осуществляется путем скрэмблирования данных так, что очень трудно и долго для неавторизованного клиента добраться до содержимого исходного текста. Авторизованные клиенты и владелец информации обычно владеет соответствующим ключом дешифрования, который позволяет им легко расшифровать текст и преобразовать его в читаемую форму. Мы рекомендуем узлам использовать шифрование для предоставления конфиденциальности и защиты важной информации. Использование шифрования определяется иногда правительственными и локальными правилами, так что мы рекомендуем администраторам быть информированными относительно законов или политик, которые регламентируют использования этой техники до ее использования. 4.3. Целостность Как администратор, вы захотите быть уверены, что информация (например, файлы операционной системы, данные компании и т.д.) не изменялась неавторизованным образом. Это означает, что вы захотите предоставить некоторую гарантию целостности информации в вашей системе. Одним из способов реализации этого является вычисление контрольной суммы исходного файла, запомнив эту контрольную сумму и периодически (или по запросу) проверяя ее, можно убедиться в том, что файл не был модифицирован. Некоторые операционные системы поставляются с программами контрольного суммирования, например, UNIX-программа суммирования. Однако, они не дают защиты, которая вам на самом деле нужна. Файлы могут быть модифицированы так, что контрольная сумма останется неизменной! Следовательно, мы советуем, чтобы вы использовали криптографически сильную программу, такую как MD5 для вычисления дайджестов, чтобы получить контрольную сумму для контроля целостности. Существуют другие приложения, где нужно гарантировать целостность, такие как передача почтовых сообщений. Доступны продукты, которые могут предоставить такую возможность. 4.4. Авторизация Авторизация относится к процессу предоставления привилегий процессам и в конечном итоге пользователям. Это отличается от аутентификации, которая осуществляет идентификацию пользователя. После надежной идентификации привилегии, права, принадлежности и разрешения определенных действий определяются авторизацией. Явное перечисление авторизованных действий для каждого пользователя (и процесса пользователя) с учетом всех ресурсов (объектов) в разумной системе невозможно. В реальной системе используются определенные методики для упрощения процесса предоставления и проверки авторизации. Один подход, популяризованный системами UNIX, заключается в присвоении каждому объекту трех классов пользователей: владелец, группа и прочий мир. Владельцем является либо создатель объекта, либо пользователь, назначенный администратором. Разрешения пользователя (чтение, запись и исполнение) предоставляются только ему. Группой является объединение пользователей, которые совместно владеют объектом. Групповыми разрешениями могут быть чтение, запись и исполнение. К остальному миру относятся все, кроме перечисленных выше. Для них может быть разрешено (или запрещено) чтение, запись и исполнение. Другим подходом является привязка к объекту списка, в котором перечислены идентификаторы всех разрешенных пользователей (или групп). Это ACL (Access Control List - список управления доступом). Преимущества ACL заключаются в том, что они легко создаются и обслуживаются (один список на объект) и очень легко визуально проверить, кто имеет доступ и к чему. Недостатком является необходимость дополнительных ресурсов, необходимых для запоминания таких списков, для больших систем нужно огромное число списков. 4.5. Доступ 4.5.1. Физический доступ Ограничение доступа к ЭВМ на физическом уровне предполагает разрешение работы только для лиц, кому это позволено. Список таких ЭВМ включает в себя терминалы (т.e., терминалы, которые допускают использование без аутентификации, такие как консоли, операторские терминалы и специальные терминалы), и индивидуальный микро-ЭВМ и рабочие станции, особенно те, которые подключены к вашей сети. Убедитесь в том, что рабочие области оформлены соответствующим образом с учетом ограничений доступа; в противном случае будут найдены пути обхода ваших физических средства безопасности (например, двери окажутся открытыми). Храните исходные и резервные копии данных и программы в безопасном месте. Помимо хранения их в хороших условиях для целей резервирования, они должны быть защищены от кражи. Важно держать резервные копии в отдельном от оригиналов месте, не только с учетом возможного повреждения, но предотвращения ущерба в случае кражи. Портативные ЭВМ подвергаются особому риску. Убедитесь, что даже кража портативной машины вашего персонала не вызовет проблем. Рассмотрите принципы обработки данных, которым разрешено храниться на дисках портативных машин, а также то, как эти данные должны быть защищены (например, шифрованием). Другими областями, где должен быть ограничен доступ, являются коммутационные шкафы и важные сетевые элементы, типа файловых серверов, DNS-серверов и маршрутизаторов. 4.5.2. Walk-up точки подключения к сети "Walk-up" соединениями, мы называем точки, где пользователи могут удобно подключать свои портативные ЭВМ к вашей сети. Рассмотрите, нужно ли вам обеспечивать такую услугу, учитывая, что это позволяет любому неавторизованному пользователю подключиться к вашей сети. Это увеличивает риск атак посредством таких методик как фальсификация IP-адресов, считывание пакетов на пролете и т.д. Пользовательский и узловой менеджмент должен учитывать сопряженные риски. Если вы допускаете такие подключения, тщательно планируйте эту услугу и точно определите, где вы это позволите с учетом безопасности физического доступа. Подключенная таким способом ЭВМ должна быть аутентифицирована до того как ее пользователю разрешен доступ к ресурсам вашей сети. В качестве альтернативы, можно рассмотреть управление физическим доступом. Например, если услуга должна использоваться студентами, вы можете установить разъемы для подключения в студенческих лабораториях. Если вы предоставляете доступ подключения портативных ЭВМ для посетителей, чтобы они устанавливали соединение с их “домашними” сетями (например, чтобы читать почту и т.д.), рассмотрите использование отдельной субсети, которая имеет соединение с внутренней сетью. Отслеживайте любую область, которая содержит немониторируемый доступ к сети, такие как свободные офисы. Может быть важным отсоединить такие области на уровне коммутационных шкафов, и рассмотреть использование безопасных разветвителей и мониторирование попыток неавторизованного подключения машин к сети. 4.5.3. Другие сетевые технологии Рассмотренные здесь технологии включают X.25, ISDN, SMDS, DDS и Frame Relay. Все они предоставляют физическое подключение через телефонные коммутаторы, что в принципе допускает перекоммутацию и несанкционированное подключение. Атакеры определенно интересуются телефонными коммутаторами также как и информационными сетями! В случае коммутационных технологий, используйте постоянные виртуальные каналы или замкнутые группы пользователей всякий раз, когда это возможно. Технологии, которые предоставляют аутентификацию и/или шифрование (например, IPv6), развиваются достаточно быстро; рассматривайте именно их, когда нужно обеспечить высокий уровень безопасности. 4.5.4. Модемы 4.5.4.1. Модемные каналы должны быть управляемы Хотя они обеспечивают удобный доступ пользователей к узлу, они могут также предоставить удобный обход firewall’а узла. По этой причине важно поддерживать соответствующий контроль использования модемов. Не позволяйте пользователям устанавливать модем без соответствующей авторизации. Это включает даже временную инсталляцию (например, включение модема в факсимильную или телефонную линию на ночь). Регистрируйте и отслеживайте состояние всех модемных линий. Проводите регулярные (в идеале автоматические) проверки узла на наличие неавторизованных модемов. 4.5.4.2. Дозванивающиеся пользователи должны быть аутентифицированы Проверка имени пользователя и пароля должна завершаться до того как пользователь получит доступ к чему-либо в сети. Соображения о нормальной безопасности паролей особенно важны (смотри раздел 4.1.1). Запомните, что телефонные линии могут быть снабжены отводами, и что достаточно легко перехватывать сообщения, посылаемые на сотовый телефон. Современные высокоскоростные модемы используют более изощренные методики модуляции, которые делают трудным их мониторирование, но разумно предположить, что хакеры знают, как прослушать ваши каналы. По этой причине, вам следует использовать одноразовые пароли. Полезно создать один пункт коммутации (например, один большой модемный пул), так что все пользователи аутентифицируются идентичным образом. Пользователи часто случайно ошибаются при вводе паролей. Установите малую задержку - скажем две секунды - после первой и второй неудачной авторизации, и осуществляйте разрыв соединения после третей неудачи. Это замедлит автоматизированные атаки паролей. Не сообщайте пользователю, что оказалось причиной неудачи: имя пользователя, пароль или оба эти ввода. 4.5.4.3. Возможность обратного дозвона Некоторые серверы подключения через модем к коммутируемой сети предлагают возможность обратного дозвона (т.e., пользователь звонит серверу и аутентифицируется, затем система рвет соединение и звонит назад пользователю по специфицированному номеру). Обратный дозвон полезен, так как, если кто-то пытается подобрать имя пользователя и пароль, система его отсоединит и свяжется с настоящим пользователем, чей пароль вскрыт; случайные звонки серверу как минимум подозрительны. Это в действительности означает, что пользователь может войти в систему только с одного места (которое прописано в сервере при конфигурации). Эта возможность должна использоваться с осторожностью, она может быть легко обойдена. Как минимум, убедитесь, что обратный дозвон производится не с того же модема, что и входной вызов. Вообще, хотя обратный дозвон может улучшить модемную безопасность, вам не следует полагаться только на него. 4.5.4.4. Все входы в систему должны регистрироваться Все авторизации, успешные или нет должны регистрироваться. Однако не храните правильный пароль в журнальном файле. Так как неверные пароли чаще всего вводятся авторизованными пользователями, они отличаются от правильных одной-двумя буквами, поэтому, если журнальный файл защищен слабо, записывать туда то, что вводили пользователи, не следует. Если доступна идентификация Calling Line (определитель номера), используйте ее преимущество путем записи номера вызова для каждой попытки авторизации. Знайте, что идентификации Calling Line не стоит слишком доверять (так как атакеры, проникая в коммутатор, переадресуют номера телефонов или осуществляют другие изменения); используйте данные только для информационных целей, а не для аутентификации. 4.5.4.5. Тщательно выбирайте открывающую метку Многие пользователи используют системную входную метку по умолчанию из файла текущего дня. К сожалению, она часто содержит тип ЭВМ или операционной системы, установленной на ЭВМ. Это может дать ценную информацию потенциальному атакеру. Вместо этого, каждый узел должен сформировать собственную входную метку, заботясь о включении туда только самой необходимой информации. Отображайте короткую метку, но не предлагайте имя пригашающего объекта (например, университет XYZ , Система записей о студентах). Вместо этого, приведите имя вашего узла, короткое предупреждение о том, что сессии могут быть отслеживаемы, и приглашение для ввода имени и пароля. Для высоко секретных приложений, рассмотрите использование "слепого" пароля (т.e., не давайте никакого отклика на ввод пользователем пароля). Это эффективно эмулирует поведение неисправного модема. 4.5.4.6. Аутентификация Dial-out Пользователи, работающие через коммутируемую сеть, также должны быть аутентифицированы, в частности, так как ваш узел должен будет оплатить телефонный вызов. Никогда не позволяйте осуществлять обратный дозвон для неаутентифицированного вызова через коммутируемую сеть, проверьте, допускаете ли вы аналогичную процедуру для аутентифицированного вызова. Целью здесь является помешать клиенту использовать ваш модемный пул для авторизации. Это может быть трудно детектировать, в частности, если хакер формирует проход через несколько ЭВМ вашего узла. Как минимум, не позволяйте использовать те же модемы и линии для прямого вызова и обратного дозвона. Это может быть легко реализовано, если вы используете разные модемные пулы для прямого вызова и дозвона. 4.5.4.7. Делайте программное обеспечение вашего модема настолько "пуленепробиваемым" насколько возможно Убедитесь, что модемы не могут быть перепрограммированы в процессе работы. Как минимум, убедитесь в том, что три знака плюс не переводят ваш модем в командный режим! Запрограммируйте ваши модемы так, чтобы они переходили в вашу стандартную конфигурацию при запуске нового вызова. Если это не получилось, заставляйте их выполнять команду сброс (reset) в конце каждого вызова. Эта предосторожность защитит вас от случайного перепрограммирования ваших модемов. Выполнение сброса в начале и конце вызова будет гарантировать даже более высокий уровень конфиденциальности, чем тот, который новый клиент может получить в наследство от предшествующей сессии. Проверьте, что ваши модемы завершают вызов корректно. Когда пользователь осуществляет уход из сервера доступа, проверьте, что сервер корректно завершил сессию и положил трубку. Важно также, чтобы сервер завершал сессию соответствующим образом, если пользователь неожиданно положил трубку. 4.6. Контрольные проверки 4.6.1. Какие данные собирать Контрольные данные должны содержать информацию о любой попытке достижения другого уровня безопасности любой персоной, процессом, или другим объектом сети. Это включает в себя авторизацию и выход из системы, доступ суперпользователя (или не-UNIX эквивалент), генерацию билета (для Kerberos, например), и любое другое изменение доступа или состояния. Особенно важно заметить "анонимный" или "гостевой" доступ к общедоступным серверам. Действительный сбор данных может отличаться для различных узлов и для различного типа изменений доступа в пределах узла. Вообще, информация, которую вы хотите собирать, включает в себя: имя пользователя и ЭВМ, для авторизации и ухода из системы; прошлые и текущие права доступа, для изменения прав доступа; и временная метка. Конечно, существует много другой информации, которая может быть собрана, в зависимости от того, на какой системе вы работаете, и сколько места имеется для записи информации. Одно очень важное замечание: не коллекционируйте пароли. Это создает опасность формирования окна потенциальной уязвимости, если записи аудита окажутся доступны. Не собирайте также и неверные пароли, так как они часто отличаются от правильных лишь одной буквой или перестановкой букв. 4.6.2. Процесс сбора данных Процесс сбора должен осуществляться ЭВМ или ресурсом, к которому производится обращение. В зависимости от важности данных и необходимости их иметь под рукой в моменты, когда происходит отказ в обслуживании, информация может храниться локально или передаваться в память после каждого события. В основном существует три способа запоминания контрольной информации: в файлы чтения/записи на ЭВМ, в устройствах с однократной записью (например, CD-ROM или специально сконфигурированный привод магнитной ленты), или с помощью аппаратуры записи типа строчного принтера. Каждый метод имеет преимущества и недостатки. Система журнальных файлов является наименее ресурсоемкой из названных методов и наиболее легко конфигурируемой. Она позволяет немедленный доступ к записям для анализа, который может быть важным в момент атаки. Система журнальных файлов является также наименее надежным методом. Если ведущая журнал ЭВМ компрометирована, файловая система является первым объектом, подвергаемым атаке; атакер без труда может скрыть следы своего вторжения. Сбор контрольных данных с помощью устройства с однократной записью требует несколько больших усилий по конфигурации, чем журнальные файлы, но имеет значительное преимущество большей безопасности, так как атакер не сможет ликвидировать следы своего вторжения. Недостатком этого метода является необходимость поддержания такого устройства и стоимость. Ведение журнала с помощью строчного принтера является полезным, когда нужен постоянный и немедленный доступ к журналам состояния системы. Примером могут служить системы реального времени, где должна быть записана конкретная точка отказа или атаки. Лазерный принтер или другое устройство, которое буферизует данные (например, сервер печати), может страдать от потери данных, если буферы содержат нужные данные в критический момент. Недостатком такого способа документирования является необходимость постоянно поддерживать принтер в состоянии готовности (бумага, другие расходуемые материалы), а также ручной просмотр записей. Существует также вопрос, где хранить огромные объемы распечаток, накапливающиеся со временем. Для каждого из описанных методов ведения журналов, существует также проблема обеспечения безопасности канала между устройством, генерирующем журнальные записи, и записывающим прибором (т.e., файл-сервером, магнитофоном/CD-ROM драйвом, принтером). Если этот путь скомпрометирован, формирование журнальных записей может быть остановлена или фальсифицирована. В идеале устройство записи журналов событий должно быть подключено с помощью одного простого кабеля по схеме точка-точка. Так как обычно это не практично, маршрут подключения должен проходить через минимальное число сетей и маршрутизаторов. Даже если журналы могут быть блокированы, фальсификация может быть предотвращена посредством криптографических контрольных сумм (вероятно, не нужно шифровать журнальные записи, так как они не содержат критической информации). 4.6.3. Нагрузка сбора данных Сбор контрольных данных может привести к заметному расходованию ресурсов памяти, так что проблема переполнения и резервирования этих ресурсов должна рассматриваться заранее. Существует много способов уменьшения требуемого объема памяти. Во-первых, данные могут быть архивированы посредством одного из стандартных методов. Или, требуемое место в памяти может быть минимизировано за счет непродолжительного хранения полных данных с последующей записью коротких резюме в долговременный архив. Главный недостаток последнего метода заключается в необходимости немедленного детектирования и реакции на инцидент. Часто инцидент имеет определенную протяженность во времени и это событие может быть замечено персоналом не сразу и потребуется определенное время, чтобы разобраться, что на самом деле происходит. В определенный момент времени оказывается крайне полезным иметь под рукой подробный журнал событий. Если имеются лишь краткие резюме, этого может оказаться недостаточно для полного анализа инцидента. 4.6.4. Обработка и сохранение контрольных данных Контрольные данные узла должны быть одними из наиболее тщательно сохраняемых, для них должны создаваться обязательно контрольные копии. Если бы атакер получил доступ к журналам контрольных данных, самой системы, риск был бы слишком велик. Контрольные данные могут также стать ключевыми для исследования, понимания и предъявления претензий инициатору инцидента. По этой причине, рекомендуется проконсультироваться с юристом узла при определении решении того, как следует обрабатывать контрольные данные. Это должно быть сделано до того, как произошел инцидент. Если план обработки данных не определен должным образом до инцидента, может случиться, что после инцидента не окажется средств восстановления из-за некорректной обработки данных. 4.6.5. Легальные соображения Благодаря содержимому контрольных данных, существует несколько юридических вопросов, которые должен разрешить юрист узла. Если вы собираете и сохраняете контрольные данные, вам нужно быть готовым к последствиям, вызванным их существованием и содержимым. Один из аспектов этой проблемы касается частной информации клиентов сети. В определенные моменты контрольные данные могут содержать определенную персональную информацию. Просмотр данных, даже с целью рутинной проверки системной безопасности, может представлять нарушение конфиденциальности. Другой аспект касается знаний об атаках, исходящих из вашего узла. Если организация хранит контрольные данные, ответственна ли она за просмотр с целью поиска инцидентов? Если ЭВМ организации используется в качестве отправной точки для атаки против другой организации, может ли эта организация использовать контрольные данные первой организации для проверки виновности (халатности)? 4.7. Контрольное копирование Процедура создания контрольных копий (backups) является классической частью операционной системы ЭВМ. В контексте данного документа резервные копии рассматриваются как часть общего плана обеспечения безопасности узла. Существует несколько важных аспектов резервного копирования, существенных в данном случае: (1) Убедитесь, что ваш узел формирует контрольные копии (2) Убедитесь, что ваш узел использует для резервного копирования запоминающее устройство за пределами узла. Расположение устройства записи должно быть тщательно выбрано с точки зрения безопасности и доступности. (3) Рассмотрите возможность шифрования ваших контрольных копий, чтобы иметь дополнительную гарантию защиты на случай, если эти данные выйдут за пределы узла. Однако, проверьте, чтобы ваша схема управления ключами была достаточно хороша для обеспечения возможности восстановления данных в любой момент в будущем. Проверьте также, чтобы вы имели доступ к необходимым программам, в любой момент, когда потребуется дешифрование. (4) Не думайте, что ваши контрольные копии всегда хороши. Часто случается при проблемах с безопасностью, что проходит много времени, прежде чем факт инцидента будет замечен. В таких случаях могут пострадать и контрольные копии. (5) Периодически проверяйте корректность и полноту ваших контрольных копий. 5. Обработка случаев нарушения безопасности Эта глава предоставляет руководство, которое следует использовать до, во время и после инцидента в ЭВМ, сети или в многоузловой системе. Философия реагирования на вторжение заключается в последовательности действий в соответствии с заранее подготовленным планом. Это должно быть так, как в случае внешней атаки, так и при нанесении непреднамеренного ущерба студентом, тестирующим некоторую новую программу, или раздраженным служащим. Каждый из возможных типов событий, таких как перечислены выше, должны иметь планы действий, подготовленные заранее. Традиционная безопасность ЭВМ, являясь крайне важной в рамках общей безопасности узла, обычно уделяет мало внимания тому, как действовать в случае, если атака действительно произошла. Результатом является то, что при атаке, многие решения принимаются в спешке и могут оказаться разрушительными для отслеживания источника инцидента, сбора данных, которые будут использованы для пресечения атаки, приготовления восстановления системы, и защиты ценных данных, содержащихся в системе. Одной из наиболее важных, но часто упускаемой выгод для эффективной обработки инцидентов, является экономический аспект. Даже при наличии технического управленческого персонала, реагирование на инцидент требует значительных ресурсов. Если персонал обучен и тренирован, то его численность может быть меньше, а работа по ликвидации инцидента эффективнее. Благодаря всемирному характеру сети большинство инцидентов не ограничиваются одним узлом. Уязвимости операционных систем относятся (в некоторых случаях) к нескольким миллионам систем, и многие слабости используются атакерами в самой сети. Следовательно, жизненно важно, чтобы все заинтересованные узлы были проинформированы об инциденте как можно быстрее. Другая выгода связана с общественным мнением. Новости об инцидентах, сопряженных с компьютерной безопасностью обычно приводит к разрушению позитивного образа организации в глазах настоящих и потенциальных клиентов. Эффективная ликвидация инцидента минимизирует негативные последствия. Последняя выгода от эффективной обработки инцидента связана юридическими обстоятельствами. Возможно, что в ближайшем будущем организации могут оказаться ответственными в случае, когда один из ее узлов использовался для сетевой атаки. Аналогично, люди, разрабатывающие корректировки программ (patches) или их доработки могут отвечать, если эти программы окажутся неэффективными, приводящими к компрометации систем, или, если эти поправки вызовут поломку программы. Разделы этой главы предоставляют обзор и перечень стартовых мер для формирования политики безопасности вашего узла при проведении работ в случае инцидентов. Это: (1) Подготовка и планирование (каковы цели и предпосылки анализа инцидентов). (2) Уведомление (с кем следует контактировать в случае инцидента). Местные менеджеры и персонал Правовое обеспечение и следственные органы Группы реагирования на инциденты, сопряженные с компьютерной безопасностью Узлы, вовлеченные или пострадавшие от инцидента Внутренние коммуникации Связь с общественностью и пресс-релизы (3) Идентификация инцидента (является ли это инцидентом и насколько он серьезен). (4) Обработка (что следует сделать, когда инцидент произошел).   Оповещение (кто должен быть уведомлен об инциденте) Журналы свидетельств и активности (какие записи до, во время инцидента и после него должны быть рассмотрены) Ограничение последствий (как можно минимизировать ущерб) Искоренение (как исключить причины инцидента) Восстановление (как восстановить услуги и системы) Ликвидация последствий (какие действия должны быть предприняты после инцидента) (5) Последствия (каковы последствия последних инцидентов). (6) Административная реакция на инцидент. 5.1 Подготовка и планирование обработки инцидентов Часть мер в случае инцидента должна быть подготовлена до того, как инцидент произойдет в первый раз. Это включает установку приемлемого уровня защиты, как это было описано в предыдущих главах. Выполнение этого поможет вам избежать инцидентов в вашем узле, а также сократить потенциальный ущерб, вызванный атакой, если она действительно произойдет. Защита включает в себя также перечень мер в случае непредвиденного инцидента в вашей организации или узле. Наличие написанных планов исключит многие неопределенности, которые могут возникнуть в случае инцидента, и приведет к более адекватному и исчерпывающему перечню действий. Жизненно важно проверить предлагаемый план до того как произойдет настоящий инцидент на пробном прогоне. Команда может даже рассмотреть наем атакующей группы, которая будет работать в параллель с пробным прогоном. (атакующая группа - это команда специалистов, которые пытаются вторгнуться в систему безопасности). Обучение эффективному реагированию на вторжение является важным по многим причинам: (1) Защита объектов, которые могут быть компрометированы (2) Защитные ресурсы, которые могли бы быть использованы с большей пользой, если инцидент не требует их услуг (3) Выполнение регламентаций (правительственных или других) (4) Предотвращение использования ваших систем в атаках против других систем (которые могут навлечь на вас юридическую ответственность) (5) Минимизация потенциала негативных проявлений При любом наборе предварительно спланированных мер, эти меры могут иметь разные приоритеты в разных узлах. Рассмотрим набор типовых мер, которые должны быть предприняты в связи с инцидентом: (1) Описать, как это произошло. (2) Выяснить, как избежать дальнейшего использование тех же самых уязвимостей. (3) Исключить последствия и будущие инциденты. (4) Оценить воздействие и ущерб от инцидента. (5) Восстановить систему после инцидента. (6) Обновить политику и процедуры, как это требуется. (7) Найти, кто это сделал (если это возможно). В силу природы инцидента может иметь место конфликт между анализом источника проблемы и восстановлением систем и услуг. Общие задачи (типа обеспечения целостности критических систем) может стать причиной отказа от анализа инцидента. Конечно, это важное управленческое решение, но все вовлеченные лица должны понимать, что без анализа тот же самый инцидент может повториться. Важно также определить заранее приоритет действий при инциденте. Иногда инцидент может быть настолько сложным, что невозможно, реагируя на него, сделать все сразу; приоритеты в этом случае крайне важны. Хотя приоритеты варьируются от организации к организации, ниже предложенные приоритеты могут служить отправной точкой для определения реакции вашей организации: (1) Приоритет номер один - защитить человеческую жизнь и безопасность людей; человеческая жизнь имеет всегда приоритет перед любыми другими соображениями.   (2) Приоритет два -- защитить категорированные и/или важные данные. Предотвратить использование категорированных и/или важных систем, сетей или узлов. Информировать подвергшиеся атаке категорированные и/или важные системы, сети или узлы об уже случившемся вторжении. (Ознакомьтесь с регламентациями вашего узла или правительства) (3) Приоритет три - защита остальной информации, включая частную, научную, управленческую и прочую, так как потеря данных стоит дорого с точки зрения ресурсов. Предотвратить использование других систем, сетей или узлов и проинформировать уже затронутые системы, сети или узлы об успешном вторжении. (4) Приоритет четыре - предотвращение разрушения систем (например, потерю или модификацию системных файлов, разрушение драйвов дисков и т.д.). Разрушение систем может вызвать дорогостоящие отказы и длительное восстановление. (5) Приоритет пять - минимизировать урон вычислительных ресурсов (включая процессы). Во многих случаях лучше закрыть систему или отключить ее от сети, чем рисковать данными или системой. Узлы должны будут сопоставить возможности закрытия, отключения и сохранения открытого состояния. Может существовать локальное соглашение обслуживания, которое требует поддержания системы в подключенном состоянии даже с учетом возможности дальнейшего разрушения. Однако ущерб и область воздействия инцидента могут быть настолько значительны, что соглашение обслуживания может быть пересмотрено. Важным выводом для определения приоритетов является то, что, если затронуты вопросы человеческой жизни и национальная безопасность, более существенным оказывается сохранение данных, чем системное программное обеспечение и оборудование. Хотя в случае инцидента нежелательно иметь любой ущерб или потерю, системы могут быть замещены. Однако, потеря или компрометация данных (особенно категорированных или частных) обычно не может быть приемлемым при любых обстоятельствах. Другой важной вещью является влияние на другие системы и сети, где имел место инцидент. В пределах ограничений, установленных правительственными регламентациями всегда важно проинформировать вовлеченные стороны как можно быстрее. Благодаря юридическим обстоятельствам этой темы это обязательно учтено в планируемых операциях, чтобы исключить дальнейшие задержки и неопределенности для администраторов. Любой план реагирования на инцидент, нарушающий безопасность, должен регулироваться локальной политикой и регламентациями. Правительственные и частные узлы, имеющие дело с категорированным материалом, имеют специфические правила, которым они должны следовать. Политики, выбранные вашим узлом и сопряженные с тем, как реагировать на инцидент, будут определять ваши действия. Например, может уделяться мало внимания созданию механизмов мониторирования и отслеживания атакеров, если ваш узел не планирует действий против них в случае поимки. Другие организации могут иметь политики, которые окажут влияние на ваши планы. Телефонные компании часто выдают информацию об отслеживании телефонных звонков только юридическим силовым агентствам. Обработка инцидентов может быть утомительным и потребует значительного числа действий от обслуживающего сеть персонала. Чтобы освободить технический персонал, может быть полезным определить круг лиц, кто будет помогать в решении таких задач как фотокопирование, отправка факсов и т.д. 5.2 Оповещение и контактные точки Важно установить контакты с различным персоналом, прежде чем произойдет реальный инцидент. Во многих случаях инциденты не являются реальными авариями. В действительности часто вы можете уладить проблему внутренними средствами. Однако, во многих случаях для разрешения проблем, сопряженных с атакой, может возникнуть необходимость привлечение структур за пределами вашей организации. Эти дополнительные контакты включают местных менеджеров и системных администраторов, административные контакты с другими узлами Интернет, и различными исследовательскими организациями. Знания об адресах, именах и телефонах этих лиц и организаций сделает решение проблемы инцидента более эффективным. Для каждого типа коммуникационного контакта должен быть определены специфические POC (Points of Contact). По своей природе они могут быть техническими или административными и могут включать юридические или сыскные агентства, а также сервис-провайдеров и поставщиков. При установлении этих контактов важно решить, какой объем информации вы готовы передать в каждом конкретном случае. Особенно важно определить заранее, какие данные вы готовы предоставить пользователям вашего узла, публике (включая прессу) и другим узлам. Решение этих вопросов особенно важно для лица, ответственного за решение проблем инцидентов, так как именно этот человек ответственен за оповещение других. Список контактов каждой из категорий сэкономит время персоналу, участвующему в ликвидации последствий инцидента. Может быть весьма трудно найти нужного человека в случае инцидента, когда осуществляется много неотложных дел. Настоятельно рекомендуется, чтобы все нужные телефонные номера (а также электронные почтовые адреса и номера факсов) были включены в политику безопасности узла. Имена и контактная информация для всех лиц, кто будет непосредственно задействован в случае инцидента, должна быть помещена в начале этого списка. 5.2.1. Локальные менеджеры и персонал Когда инцидент произошел, главный вопрос, который надо решить, кто отвечает за координацию действий всех участников работ. Главная ошибка, которая может произойти, заключается в том, что много людей работает независимо, не координируя своих усилий. Это только добавит неразберихи и, вероятно, приведет к потере времени и неэффективности. Единой POC может быть человек, ответственный за ликвидацию последствий инцидента. Могут быть разные роли у лиц, являющихся контактными персонами и координаторами работ по данному инциденту. Руководитель бригады будет принимать решения, как следует интерпретировать политику безопасности в приложении к данному конкретному инциденту. Напротив, POC должен координировать усилия всех участников, вовлеченных в работы. POC должен быть человек с техническим опытом успешной координации усилий системных менеджеров и пользователей, вовлеченных в мониторинг и реагирование на атаки. Такую кандидатуру нужно выбирать весьма тщательно. Это не должен быть человек, кто отвечает административно за скомпрометированную систему, так как часто такие администраторы имеют знания, необходимые для рутинного управления сетью и ЭВМ день за днем, и не владеют достаточным техническим опытом. Другой важной функцией POC является поддержание контакта с юридическими силовыми и другими внешними агентствами, чтобы обеспечить их конструктивное участие. Уровень вовлечения будет определяться управленческими решениями администрации и юридическими регламентациями. Одна POC должна быть представлена одним человеком, ответственным за сбор фактического материала, так как чем больше людей, которые имели контакт с потенциальной уликой, тем больше вероятность того, что это будет неприемлемо в суде. Чтобы гарантировать, что улика будет принята юридическим сообществом, сбор улик должен быть выполнен согласно заранее определенной процедуре в соответствии с местными законами и юридическими регламентациями. Одной из наиболее критических задач POC является координация всех важных процессов. Ответственности могут быть распределены по всему узлу, включая многие независимые отделы или группы. Это потребует хорошо скоординированных усилий, для того чтобы достичь конечного успеха. Ситуация становится даже более сложной, если в инцидент вовлечено несколько узлов. Когда это случается, вряд ли один контактный человек (POC) в одном узле будет способен успешно координировать все работы, сопряженные с инцидентом. Вместо этого, должна быть создана специальная команда, предназначенная для работы по этому инциденту. Процесс реагирования на инцидент должен предусматривать некоторые механизмы эскалации. Для того чтобы определить такой механизм, узлы будут должны сформировать внутреннюю схему классификации инцидентов. Каждому уровню инцидента будут поставлены в соответствие определенные POC и процедуры. Если инцидент развивается, возможна смена POC, который будет должен взаимодействовать с другими людьми, вовлеченными в ликвидацию последствий инцидента. Когда происходит замена POC, прежний контактный человек должен кратко проинформировать нового POC обо всех обстоятельствах. Наконец, пользователи должны знать, как сообщать о предполагаемых инцидентах. Узлы должны установить процедуры докладов, которые будут осуществляться как во время, так и вне нормальных рабочих часов. В дневные рабочие часы такие доклады могу приниматься в специальных справочных бюро, в то время как в остальное время могут использоваться пейджеры или телефоны. 5.2.2. Юридические силовые и следственные агентства В случае инцидента, который имеет легальные последствия, важно установить контакт со следственными агентствами (например, ФБР или Секретная служба США) так быстро, как только возможно. Местные силовики, локальные службы безопасности и департаменты полиции кампуса должны быть также оповещены. В этом разделе описываются многие вопросы, с которыми придется столкнуться, но признается, что каждая организация может иметь свои собственные местные и государственные законы и регламентации, которые будут оказывать сильное влияние на то, как будут осуществляться взаимодействие с юридическими и следственными агентствами. Первоначальной причиной определения этих точек контакта заранее является то, что в случае реального инцидента имеется слишком мало времени, чтобы выяснять, с кем конкретно надо контактировать. Другой причиной является то, что важно сотрудничать с этими агентствами в стиле, способствующем хорошим деловым отношениям, и соответствующем традициям этих ведомств. Знания рабочих процедур заранее, и схемы контактов является большим шагом в правильном направлении. Например, важно собрать сведения о том, что допустимо при любых последующих юридических действиях, а это потребует предварительного знания о том, как собирать улики. Последняя причина для установления контактов как можно быстрее заключается в том, что невозможно знать конкретное агентство, в юрисдикции которого находится конкретный инцидент. Осуществление контактов и нахождение подходящих каналов заранее позволит осуществить работу по инциденту значительно более спокойно. Если ваша организация или узел имеет юриста, вам нужно как можно скорее уведомить юридическую службу о факте инцидента. Как минимум ваш адвокат должен подключиться к защите юридических и финансовых интересов вашего узла или организации. Существует много правовых и практических вопросов, среди них: (1) Хочет ли ваш узел или организация рисковать отрицательной рекламой или открытым сотрудничеством в сфере юридического или судебного преследования виновников. (2) Несение ответственности. Если вы оставляете скомпрометированную систему, как она есть, то имеется возможность того, что она станет источником атаки для другой машины, а ваша организация или узел может нести ответственность за причиненный ущерб. (3) Распространение информации. Если ваш узел или организация распространяет информацию об атаках, в которые были вовлечены другие узлы или организации или уязвимостях программных продуктов, которая может повлиять на сбыт продукта, ваш узел или организация может быть обвинена в нанесении ущерба (включая ущерб репутации). (4) Ответственность за мониторинг. Ваш узел или организация могут преследоваться по суду, если пользователи вашего узла узнают, что производится мониторинг аккаунтов, не информируя об этом пользователей. К сожалению, нет пока очевидных прецедентов преследования или ответственности организаций, вовлеченных в инцидент утраты безопасности. Расследователи будут часто просить организации отследить или мониторировать активность атакеров. Действительно, большинство расследователей не может отследить компьютерные вторжения без энергичной поддержки вовлеченных организаций. Однако, расследователи не могут предоставить защиту против обвинений в нарушении конфиденциальности, и эта деятельность может тянуться месяцами, отнимая много усилий. С другой стороны, юрист организации может посоветовать соблюдать предельную осторожность и предложить, чтобы отслеживание атакера было прекращено, а его доступ в систему закрыт. Это, по сути, не даст защиты от обвинений и может помешать расследователям идентифицировать злоумышленника. Баланс между поддержкой следственной активности и ограничением ответственности является лукавым. Вам будет нужно рассмотреть совет вашего юриста и ущерб, причиненный атакером (если таковой имеется), когда принимаете решение о том, что делать при конкретном инциденте. Ваш юрист должен быть также подключен к принятию решения о контакте со следственным агентством, когда инцидент произошел в вашем узле. Решение координировать усилия со следственными агентствами является наиболее разумным для вашего узла или организации. Подключение вашего юриста будет также стимулировать многоуровневую координацию между вашим узлом и конкретным привлеченным следственным агентством, которое в свою очередь приведет к эффективному разделению труда. Попутно вы получите руководство, которое поможет вам избежать будущих юридических ошибок. Наконец, ваш юрист должен оценить инструкции вашего узла по преодолению инцидентов. Существенно получить "чистое карантинное свидетельство" с юридической стороны, прежде чем вы действительно выполните эти процедуры. Жизненно важно, при работе с следственными агентствами, проверять то, что человек, запрашивающий информацию, является официальным представителем оговоренного агентства. К сожалению, многие благонамеренные люди допускают непреднамеренную утечку важных данных об инциденте, допуская неавторизованных лиц в свою систему и т.д., так как гость выдает себя за представителя правительственного агентства. (Заметим, эта предосторожность относится ко всем внешним контактам). Так как многие сетевые атакеры могут легко переадресовать почтовые сообщения, избегайте использования электронной почты для взаимодействия с другими агентствами (а также с другими, имеющими отношения к инциденту). Обычные телефонные линии являются также частой мишенью для атак посредством подключения, так что будьте осторожны! Не существует ни одного установленного набора правил реагирования на инцидент, когда оказываются вовлечены местные административные органы. В норме (в США), за исключением оговоренных законом случаев, ни одно агентство не может заставить вас мониторировать сеть, отсоединиться от сети, исключить телефонный контакт с подозреваемым атакером и т.д. Каждая организация имеет набор местных и национальных законов и регламентаций, которые должны строго выполняться при обработке инцидента. Рекомендуется, чтобы каждый узел был знаком с этими законами и регламентациями, и знал агентства и их юрисдикцию заранее до наступления инцидента. 5.2.3. Группы обслуживания случаев нарушения безопасности Сейчас существует несколько бригад по ликвидации инцидентов CSIRT (Computer Security Incident Response teams), таких как Координационный центр CERT, Германский DFN-CERT и другие команды разбросанные по всему миру. Команды существуют во многих правительственных агентствах и больших корпорациях. Если имеется такая команда, ее оповещение должно быть главным приоритетом на ранних стадиях инцидента. Эти команды ответственны за координацию действий в области сетевой безопасности больших объединений узлов и других крупных объектов. Даже если инцидент ограничен одним узлом, возможно, что информация, имеющаяся в команде по ликвидации инцидентов, может помочь решить проблемы, связанные инцидентом. Если определено, что уязвимость возникла благодаря пороку в системном оборудовании или программе, об этом должны быть проинформированы немедленно изготовитель (или поставщик) и команда по ликвидации инцидента. Это особенно важно, так как многие другие системы уязвимы и эти поставщики и команды могут помочь другим потенциально уязвимым узлам. При формировании политики узла в отношении инцидентов, может быть желательно создать субгруппу, очень похожую на уже существующие бригады, которая будет ответственна за обеспечение безопасности узла (или организации). Если такая команда создана, существенно, чтобы были открыты коммуникационные линии между этой и другими аналогичными командами. Когда инцидент произошел, трудно открыть доверительный диалог между разными командами, если их не существует. 5.2.4. Узлы, вовлеченные в инцидент Если инцидент имеет воздействие на другие узлы, хорошей практикой можно считать информирование их об этом. То, что инцидент затрагивает не только местный узел, может стать понятно с самого начала, или это может быть выяснено только после некоторого анализа. Каждый узел может выбрать, контактировать ли с другими узлами непосредственно или передать информацию через соответствующую команду реагирования на инциденты. Часто очень трудно найти ответственного POC удаленных узлах, а команда реагирования на инциденты будет способна облегчить контакт, используя уже сформированные каналы связи. Вопросы ответственности и юридические аспекты варьируются от узла к узлу. Важно определить политику рассылки и записи информации, до того как инцидент произошел. Информация о конкретных людях является особенно уязвимой, и может быть объектом законов о конфиденциальности. Чтобы избежать проблем в этой сфере, не относящаяся к делу информация должна быть стерта, а в правила работы с остальной информацией должны быть включены в описание политики. Команды реагирования на инциденты уязвимы с этой точки зрения. Когда они передают информацию ответственным POC, они могут защитить анонимность исходного источника. Но будьте уверены, что во многих случаях, анализ журнальных записей и информации о других узлах раскроет адреса вашего собственного узла. Все проблемы, обсужденные выше не должны рассматриваться в качестве причин не подключения других узлов. Фактически, опыт существующих команд показывает, что большинство узлов, информированные о проблемах безопасности, даже не подозревают, что их сеть также компрометирована. Без своевременной информации другие узлы часто неспособны предпринять какие-либо меры против вторжения. 5.2.5. Внутренние коммуникации При крупном инциденте важно сообщать, почему предприняты те или иные действия, и что собираются предпринять пользователи (или подразделения). В частности, должно быть объяснено пользователям, что им позволено говорить (и не говорить) внешнему миру (включая другие отделы). Например, не было бы хорошо для организации, если пользователи отвечают что-то вроде, "Извините, системы отключены, имеет место вторжение, и мы пытаемся со всем этим разобраться". Будет много лучше, если они будут проинструктированы откликаться заранее подготовленным заявлением типа, "Извините, наши системы недоступны, они подготавливаются для улучшения услуг". Взаимодействия с клиентами и контактными партнерами должны поддерживаться в благоразумном и деликатном стиле. Можно подготовить контрольный список. Когда инцидент произойдет, этот список может быть использован с добавлением одной - двух фраз, учитывающих специфические обстоятельства инцидента. Отделы связей с общественностью могут быть очень полезными при инцидентах. 5.2.6. Взаимодействие с обществом - пресс-релизы В США средства массовой информации уделяют большое внимание проблемам сетевой безопасности. Заметный рост интереса к этой тематике наблюдается и в других странах. Читатели из стран, где средства массовой информации не уделяют сетевым проблемам сходного внимания, могут использовать опыт США. Одним из наиболее важных вопросов, которые нужно рассмотреть, является когда, кто и сколько данных нужно передать прессе в случае инцидента. Во-первых, если отдел связей с общественностью в узле существует, важно использовать этот отдел для связи с прессой. Отделы связей с общественностью имеет преимущество в том, что вы можете говорить с ними откровенно, и иметь буфер между постоянным вниманием прессы и необходимостью иметь контакт, сохраняя управление в ходе преодоления последствий инцидента. Если отдела связей с общественностью нет, информация выдаваемая прессе должна тщательно анализироваться. Если информация важна, прессе следует выдавать по минимуму лишь обзорные данные. Вполне возможно, что любая информация, предоставленная прессе, будет быстро доступна инициатору инцидента. Заметим также, что введение в заблуждение прессы может иногда нанести больший ущерб, чем разглашение какой-то важной информации. Так как бывает трудно заранее определить, какой уровень детализации нужно предоставить прессе, следует держать в уме следующие соображения: (1) Сохраняйте на низком уровне технические детали инцидента. Детальная информация об инциденте может предоставить достаточно данных для других лиц, которые могут предпринять аналогичные атаки на другие узлы, или даже помешать узлу преследование виновных по завершению инцидента. (2) В заявлениях для прессы не допускайте предположений. Предположения о том, кто является виновником инцидента или о мотивах действий весьма вероятно окажутся неверными и могут вызвать неверную интерпретацию событий. (3) Сотрудничайте с силами правопорядка, чтобы гарантировать сохранение улик. Если предполагается преследование виновника, следите, чтобы собранные улики не просочились в прессу. (4) Старайтесь не давать интервью, до тех пор пока вы не будете к нему готовы. (5) Не допускайте, чтобы внимание прессы отвлекало от ликвидации последствий инцидента. Всегда помните, что успешное сокрытие инцидента имеет первостепенное значение. 5.3. Идентификация инцидента 5.3.1. Он действительно имел место? Этот этап включает определение того, имеется ли проблема вообще. Конечно, многие, если не все признаки, часто ассоциируемые с вирусной инфекцией, вторжениями в систему, злонамеренными пользователями и т.д., являются просто аномалиями, такими как отказ оборудования или подозрительное поведение системы/пользователя. Чтобы помочь определить, имеет ли место инцидент, обычно полезно получить и использовать любую доступную детектирующую программу. Контрольная информация является также крайне полезной, особенно при определении того, имеет ли место сетевая атака. Чрезвычайно важно как можно быстрее записать состояние системы, как только возникло малейшее подозрение на атаку. Многие инциденты вызывают динамическую цепочку событий, и анализ исходного состояния системы может быть наиболее ценным инструментом для идентификации проблемы и источника атаки. Наконец, важно запустить систему журнальных файлов. Запись системных событий, телефонных переговоров, временных меток и т.д., может привести к более быстрому и систематическому выявлению проблемы, и является основой для дальнейшей работы над инцидентом. Существуют определенные указания или "симптомы" инцидента, которые заслуживают особого внимания: (1) Аварии системы (2) Аккаунты новых пользователей (неожиданно создан аккаунт RUMPLESTILTSKIN), или необычно высокая активность на аккаунте, который был обычно мало активен. (3) Новые файлы (обычно с новыми или странными именами, такими как data.xx или k или .xx). (4) Рассогласование аккаунтингов (в системе UNIX вы можете заметить сжатие файлов аккаунтинга, называемого /usr/admin/lastlog, все что вызывает подозрение может быть результатом действия атакера). (5)   (6) Попытки записи в системные файлы (системный менеджер заметил, что привилегированный пользователь в системе VMS пытается отредактировать RIGHTSLIST.DAT). (7) Модификация или стирание данных (файлы начинают исчезать). (8) Отказ в обслуживании (системный менеджер и другие пользователи оказываются блокированы в системе UNIX, система перешла в режим с одним пользователем). (9) Необъяснимое, плохое поведение системы (10) Анормальности (на дисплее отображается "GOTCHA" или частые необъяснимые звуковые сигналы). (11) Подозрительные попытки (имеют место множественные неуспешные попытки авторизоваться из другого узла). (12) Подозрительный просмотр (кто-то становится пользователем root системы UNIX и открывает файл за файлом, принадлежащие разным пользователям). (13) Невозможность пользователя авторизоваться из-за модификаций его/ее аккаунта. Этот список не является исчерпывающим; мы лишь перечислили несколько общих индикаторов. Лучше всего сотрудничать с техническим персоналом и лицами, ответственными за безопасность, чтобы принять совместное решение, произошел инцидент или нет. 5.3.2. Типы инцидентов Помимо идентификации инцидента нужно определить область и воздействие проблемы. Важно корректно идентифицировать границы инцидента, для того чтобы эффективно его проанализировать и расставить приоритеты реагирования. Для того чтобы идентифицировать область и воздействие надо определить набор критериев, которые соответствуют данному узлу и типу доступных соединений. Ниже представлены некоторые вопросы: (1) Охватывает ли данный инцидент несколько узлов? (2) Инцидент затронул много ЭВМ вашего узла? (3) Вовлечена ли важная (чувствительная) информация? (4) Что является входной точкой атаки (сеть, телефонная линия, локальный терминал и т.д.)? (5) Вовлечена ли пресса? (6) Каков потенциальный ущерб инцидента? (7) Каково ожидаемое время улаживания инцидента? (8) Какие ресурсы нужны на ликвидацию инцидента? (9) Подразумевается ли привлечение юридической поддержки? 5.3.3. Оценка ущерба и его масштаба Анализ ущерба и масштаба инцидента может занять много времени, но непременно должен вести к пониманию природы инцидента и иметь целью расследование и нахождение виновника. Как только обнаружено проникновение, вся система и все ее компоненты оказывается под подозрением. Системное программное обеспечение является наиболее вероятной мишенью. Подготовленность является ключом для способности детектировать все изменения возможно поврежденной системы system. Это включает контрольное суммирование всех носителей, используя алгоритм, устойчивый для злоупотреблений (смотри разделы 4.3). Предполагая, что данные о дистрибутивах доступны, должен проводиться анализ всех системных файлов, и любые нерегулярности должны регистрироваться и передаваться всем вовлеченным в инцидент. В некоторых случаях может быть очень трудно решить, какая из резервных сред демонстрирует корректное состояние системы. Предположим, например, что инцидент может продолжаться месяцы или годы, прежде чем все станет ясно, а подозреваемым может быть сотрудник узла. В любом случае, подготовка к инциденту определяет возможность преодоления последствий инцидента. Если система поддерживает централизованное ведение журнальных файлов (как правило, это так), просмотрите записи и ищите любые необычные события. В меньшей мере, на инцидент может пролить свет использование диска. Аккаунтинг может предоставить много полезной информации при анализе инцидента и последующего поиска виновника. 5.4. Обработка инцидентов Необходимы определенные шаги, необходимые при работе над инцидентом. В любой активности, сопряженной с безопасностью, наиболее важным моментом является необходимость того, чтобы все узлы имели политику безопасности. Без определения политики и целей, предпринимаемые действия лишены координации. Цели должны быть определены менеджментом и юристом заранее. Одним из главных целей является восстановление управления системами, подверженными атаке и ограничение размера ущерба. В худшем случае выключение системы или отключение системы от сети могут стать единственными практическими решениями. Так как операция достаточно сложна, попытайтесь получить всю необходимую помощь. В то время как при попытке решить проблему в одиночку, размер ущерба может увеличиться из-за задержек или потери информации. Большинство администраторов воспринимают поиск атакера как личный вызов. Поступая таким образом можно упустить из внимания многие важные аспекты локальной политики безопасности. Попытка поимки хакера может оказаться задачей с очень низким приоритетом, по сравнению, например, с целостностью системы. Мониторирование хакерской активности полезно, но это не сопоставимо с риском, сопряженным с продолжением разрешения незаконного допуска. 5.4.1. Типы уведомлений и обмен информацией Когда вы убедились, что инцидент имел место, должен быть проинформирован соответствующий персонал. То, как это оповещение реализуется, очень важно для сохранения ситуации под контролем с технической и эмоциональной точек зрения. Обстоятельства должны быть описаны как можно подробнее, с целью быстрого уведомления и понимания проблемы. Нужно тщательно определить, каким группам дается исчерпывающая техническая информация при оповещении. Например, целесообразно передать такого рода данные команде по ликвидации последствий атаки, так как они могут помочь вам выработать советы по ликвидации уязвимостей, сопряженных с инцидентом. С другой стороны, делая критическую информацию общедоступной (например, через группу новостей USENET или подписной лист), вы можете потенциально подвергнуть риску атаки большое число других систем. Правильно предположить, что все администраторы, читающие данную группу новостей, имеют доступ к текстам программ операционной системы или могут даже понять, как можно реализовать подобные шаги. Прежде всего, любое оповещение местного или внешнего персонала должно быть непосредственным. Это требует, чтобы любое заявление (по электронной почте, телефону, факсом, через пейджер или любым другим способом) предоставляло информацию об инциденте ясно, кратко и профессионально. Другим важным соображением при уведомлении об инциденте является строгое следование фактам. Попытка скрыть некоторые аспекты инцидента, предоставляя некорректную или неполную информацию, может не только помешать успешному преодолению инцидента, но даже ухудшить ситуацию. Выбор используемого языка при уведомлении людей об инциденте может иметь важное влияние на то, как будет получена информация. Когда вы используете эмоциональные выражения, вы увеличиваете потенциал ущерба и негативных последствий инцидента. Важно оставаться спокойным как при письменных, так и при голосовых коммуникациях. Другим соображением является то, что не все люди говорят на одном языке. Благодаря этому факту, могут возникнуть недоразумения и задержки, особенно, если инцидент является интернациональным. Другие международные соображения включают в себя различия в юридических последствиях инцидента и различия в сфере культуры. Однако культурные различия существуют не только между странами. Они существуют даже внутри стран, между различными социальными и пользовательскими группами. Например, администратор университетской системы может не волноваться по поводу попыток соединиться с системой через telnet, но администратор военной системы рассмотрит аналогичную попытку, как потенциальную атаку. Другим аспектом, связанным с выбором языка, является оповещение нетехнического персонала или лиц не связанных с данным узлом. Важно аккуратно описать инцидент без неуместного ажиотажа или неразберихи. В то время как много труднее описать инцидент нетехнической аудитории, это часто более важно. Нетехническое описание может потребоваться для менеджмента верхнего уровня, прессы или при связи с юридическими подразделениями. Важность этих коммуникаций не может быть недооценена и может привести и к разрешению инцидента и к его эскалации. Если привлекается команда по ликвидации последствий инцидента, может быть нужно, заполнить форму для информационного обмена. Хотя это может показаться дополнительной нагрузкой и приводит к определенным задержкам, это помогает команде действовать с минимальным набором информации. Команда реагирования может быть способна действовать в отношении некоторых аспектов инцидента, о которых местный администратор не проинформирован. Если информация передана кому-то еще, должен быть предоставлен следующий минимум данных: (1) Временная зона журнальных записей, в формате GMT или местное время (2) Информация об удаленной системе, включая имена ЭВМ, IP-адреса и (может быть) ID пользователей (3) Все журнальные записи, связанные с удаленным узлом (4) Тип инцидента (что случилось, почему вы должны принять меры) Если локальная информация (т.e., ID местного пользователя) включена в журнальные записи, будет необходимо отредактировать записи, чтобы избежать нарушения конфиденциальности. Вообще, вся информация, которая может помочь удаленному узлу решить проблему, связанную с инцидентом, должна быть предоставлена, если только это не противоречит местной политике безопасности. 5.4.2. Защита улик и журнальные записи активности Когда вы реагируете на инцидент, документируйте все детали, связанные с инцидентом. Это даст важную информацию для вас и других, если вы захотите восстановить картину событий. Документирование всех деталей, несомненно, сэкономит ваше время. Если вы не документируете каждый имеющий отношение к инциденту телефонный разговор, например, вы, возможно, забудете важную информацию, которую вы получили, требуя повторного контакта с источником данной информации. В то же время, запись деталей предоставит улики для последующего расследования. Документирование инцидента поможет также вам выполнить окончательную оценку ущерба (ваше начальство и следственные органы запросят вас об этом), а также даст основу для последующих фаз работы по проблематике инцидента: подавление, восстановление и доведение до конца "полученных уроков". Во время начальных фаз инцидента, часто трудно определить, возможно, ли преследование виновника, так что вы должны документировать все, как если бы вы собирали улики для суда. Как минимум, вам следует записывать: (1) Все системные события (audit records) (2) Все ваши действия (снабженные временными метками) (3) Все внешние переговоры (включая имена лиц, с которыми вы говорите, дата, время и содержание разговора) Наиболее прямой способ документирования - ведение журнальных файлов. Это позволяет вам получить централизованный, хронологический источник информации, когда вам это нужно, вместо записи данных на листы бумаги. Большая часть этой информации является уликами для будущего судебного процесса. Таким образом, когда возможно последующее юридическое расследование, следует придерживаться определенных процедур и избегать риска юридических процедур при некорректном обращении с уликами. Если приемлемо, могут быть предприняты следующие шаги. (1) Регулярно (например, каждый день) включайте копирование подписанных копий вашего журнала событий (а также среды, которую вы используете для записи системных событий). (2) Хранитель (custodian) должен хранить копии этих страниц в безопасном месте (например, в сейфе). (3) Когда вы предоставляете информацию для записи, вы должны получить подписанный, датированный доклад от хранителя документов. Нарушение в процессе реализации этих процедур может привести к тому, что любые улики, которые вы получили, будут признаны в суде недействительными. 5.4.3. Противодействие Целью противодействия является ограничение масштабов развития атаки. Существенной частью противодействия является принятие решения (например, определение, следует ли выключить систему, отключить ее от сети, мониторировать систему или сетевую активность, установить ловушки, закрыть функции, такие как удаленная передача файлов и т.д.). Иногда это решение тривиально - выключить систему, если информация категорирована, чувствительна или является частной. Учтите, что аннулирование всякого доступа при инциденте обращает на себя внимание всех пользователей, включая подозреваемых, что может иметь вредное воздействие на расследование. В некоторых случаях, разумно ликвидировать все виды доступа или функциональность так быстро, как только возможно, а затем поэтапно восстановить нормальную работу. В других случаях, имеет смысл рискнуть, если сохранение системы в рабочем состоянии поможет идентифицировать виновника инцидента. Этот этап должен включать в себя выполнение определенных заранее процедур. Ваша организация или узел должны, например, определить приемлемые риски в ходе преодоления последствий инцидента, и предложить соответствующие действия и стратегии. Это особенно важно, когда необходимо быстрое решение и невозможно при первом контакте заинтересованных сторон обсудить возможное решение. В отсутствии определенных заранее процедур лицо, ответственное за ликвидацию последствий инцидента, не имеет полномочий принимать сложные управленческие решения (вроде потери результатов сложного эксперимента при отключении системы). Данный этап завершается оповещением всех заинтересованных полномочных представителей. 5.4.4. Подавление Когда факт инцидента установлен, наступило время ликвидации последствий и причин. Но прежде чем устранять причины, должны быть приняты меры по сбору всей необходимой информации о компрометированных системах и причинах инцидента, так как эти данные будут потеряны после полной очистки системы. Помощь в ликвидации причин и последствий инцидента могут оказать специальные программы, такие, например, как антивирусные. Если атакером были созданы какие-либо файлы, архивируйте их прежде чем уничтожать. В случае вирусного заражения важно очистить и повторно отформатировать среду, содержащую инфицированные файлы. Наконец, убедитесь, что все резервные копии не содержат зараженных файлов. Многие системы, инфицированные вирусами, повторно заражаются просто потому, что народ своевременно не удаляет вирусы с контрольных копий. После ликвидации причин и последствий следует сформировать новые контрольные копии (backup). Удалить все уязвимости после инцидента достаточно трудно. Ключевым моментом при ликвидации слабостей системы является понимание характера уязвимостей. Может быть, необходимо взять исходный дистрибутив и заново сформировать систему. Чтобы облегчить наихудший сценарий следует записать установочную конфигурацию системы и каждое изменение конфигурации. В случае сетевой атаки важно инсталлировать все коррекции программ (patches) для каждой уязвимости операционной системы, которая может быть использована для атаки. Как это описано в разделе 5.4.2, журнальные записи безопасности могут оказаться наиболее ценными на фазе ликвидации уязвимостей. Журнальные записи показывающие, как инцидент был обнаружен и локализован, могут быть полезны позднее, чтобы помочь определить насколько велик был ущерб от данного инцидента. В идеале, следует автоматизировать и регулярно использовать тест для выявления инцидентов, сопряженных с безопасностью. Если конкретная уязвимость локализована, следующим шагом является нахождения механизмов защиты системы. Информацию для решения этой проблемы можно найти с помощью тематических подписных листов и бюллетеней, целесообразно проконсультироваться в группах по ликвидации последствий инцидентов. 5.4.5. Восстановление Когда причина инцидента устранена, следующим этапом становится ликвидация последствий и восстановление системы. Целью восстановления является возвращение системы в нормальное состояние. Вообще, восстановление услуг в порядке запросов является оптимальной стратегией и минимизирует неудобства пользователей. Поймите, что правильные процедуры восстановления системы крайне важны и должны быть специфицированы для узла заранее. 5.4.6. Доработка Когда вы поняли, что система восстановлена и приведена в безопасное состояние, вполне возможно, что в системе безопасности сохранились дыры и даже ловушки, допускающие отслеживание системы. Одним из важных этапов реагирования на инцидент довольно часто упускается, это фаза доводки системы безопасности. На фазе доводки, система должна мониторироваться на предмет объектов, которые оказались пропущены на предыдущей фазе. Было бы благоразумным использовать некоторые средства, упомянутые в главе 7. Наиболее важным элементом стадии доводки является выполнение анализа инцидента и его последствий. Что конкретно случилось, и когда? Насколько эффективно действовал персонал во время инцидента? В какой информации персонал нуждается в первую очередь, и как такую информацию получить как можно быстрее? Что следует сделать персоналу по другому в следующий раз? После инцидента, разумно написать доклад, описывающий точную последовательность событий: метод обнаружения, процедура коррекции, процедура мониторинга и резюме полученного опыта. Это поможет ясно понять проблему. Создание формальной хронологии событий (включая временные метки) важно также по юридическим причинам. Доклад доводки является ценным по многим причинам. Он используется в случае возникновения других сходных инцидентов. Важно также как можно быстрее получить денежную оценку ущерба, вызванного инцидентом. Эта оценка должна включать суммы, связанные с потерей программ и файлов (особенно стоимость частных данных, которые могут быть раскрыты), выхода из строя оборудования и трудозатраты для восстановления измененных файлов, реконфигурации поврежденных систем и пр. Эта оценка может стать основой для последующего преследования виновных. Доклад может помочь руководству составить представление о состоянии сетевой безопасности организации. 5.5. Последствия инцидента В связи с инцидентом нужно предпринять ряд действий. Эти действия перечислены ниже: (1) Должна быть проведена инвентаризация всех повреждений (т.e., в результате тщательного осмотра должно быть определено, насколько система пострадала от инцидента). (2) Чтобы исключить возможность такого вторжения, план безопасности должен быть скорректирован с учетом опыта, извлеченного после инцидента. (3) С учетом данного инцидента должен быть произведен новый анализ рисков. (4) Расследование и наказание лиц, виновных в инциденте, если это считается желательным. Если инцидент явился результатом неудачной политики безопасности, и если политика не изменена, тогда повторение инцидента неизбежно. Как только узел оправился после инцидента, политика узла и процедуры должны быть тщательно рассмотрены и в них должны быть внесены изменения, чтобы предотвратить подобные инциденты в будущем. Даже в отсутствии инцидентов, представляется разумным пересматривать политику и процедуры на регулярной основе. Эти пересмотры обязательны с учетом современных изменений компьютерной среды. 5.6. Ответственность 5.6.1. Не пересекая черту Одно дело - защитить свою собственную сеть, но совершенно другое, предположить, что нужно защищать другие сети. В процессе разрешения проблемы инцидента становятся очевидными определенные слабости системы. Достаточно легко и даже соблазнительно найти виновника инцидента, но это не всегда оптимальный путь. Наилучшее правило, когда это касается права собственности, никогда не использовать ни одно из средств удаленного узла, если оно не является общедоступным. Это ясно исключает любой вход в систему (такой как rsh или сессия авторизации), который не разрешен явно. Может показаться очень привлекательно, после того как уязвимость безопасности определена, испытать эту слабость на соседе и проверить, уязвим ли удаленный узел. Не делайте этого! Вместо этого, попытайтесь установить контакт с пострадавшим узлом. 5.6.2. Хорошее гражданство в Интернет При инциденте имеется два варианта поведения. В первом, узел может выбрать слежение за атакером с надеждой поймать его; или, узел может заняться очисткой системы и предотвращением дальнейшего проникновения в нее атакера. Это решение должно приниматься весьма обдуманно, так как может возникнуть юридическая ответственность, если вы решите оставить ваш узел открытым, а хакер воспользуется вашим узлом в качестве стартовой площадки для атаки других узлов. Быть хорошим гражданином Интернет означает, что вы должны стараться предупреждать прочие узлы, что они могут подвергнуться атаке. 5.6.3. Административная реакция на инцидент Когда инцидент с безопасностью затрагивает пользователей, политика безопасности должна описывать, какие действия следует предпринять. Злоупотребления должны рассматриваться как серьезные проступки, но очень важно быть уверенным в роли, которую в инциденте играл пользователь. Был ли пользователь наивным? Возможна ли ошибка в обвинении пользователя? Принятие административных мер, исходя из предположения преднамеренных действий, к пользователю, который совершил лишь ошибку, нельзя признать адекватным. Может быть более адекватным включение в вашу политику других более приемлемых санкций (например, обучение или замечание) в дополнение к более строгим мерам для преднамеренных действий по вторжению и недопустимому использованию системы. 6. Проводимые действия На данный момент в вашем узле, надо полагать, полностью разработана политика безопасности и процедуры для конфигурации и управления вашей технологией поддержки этой политики. Как было бы здорово, если бы вы могли отсесть и расслабиться, будучи уверенны, что вы закончили работу с безопасностью. К сожалению, это невозможно. Ваши системы и сети не являются статическими, так что вам придется пересматривать политику и процедуры на регулярной основе. Существует много путей, которыми вы можете воспользоваться, чтобы решить проблему обновления. Ниже предлагается начальный набор, который вы можете дополнить с учетом требований вашего узла. (1) Подпишитесь на справочную рассылку, которая осуществляется различными командами, которые специализируются на сетевых инцидентах, например, координационный центр CERT, и обновите ваши системы, чтобы избежать угроз, которые могут быть реализованы при технологии, используемой в вашем узле. (2) Отслеживайте и используйте программные поправки (patches), которые предлагаются поставщиком вашего оборудования. (3) Активно контролируйте конфигурацию ваших систем, чтобы идентифицировать любые изменения, которые могли произойти, и исследуйте все аномалии. (4) Ежегодно (как минимум) пересматривайте политику безопасности и все процедуры. (5) Читайте соответствующие почтовые списки рассылки и группы новостей USENET, чтобы быть в курсе всех новейших событий и знать обо всех важных новостях, сообщаемых вашими коллегами администраторами. (6) Регулярно проверяйте согласованность политики и процедур. Эта проверка должна выполняться человеком, который не принимал участие в формировании политики и процедур. 7. Средства и их размещение В этой главе предлагается краткий список общедоступных технологий безопасности, реализации которых могут быть найдены в Интернет. Большинство программных средств и приложений, описанных ниже можно найти в одном из ниже указанных депозитариев: (1) Координационный центр CERT ftp://info.cert.org:/pub/tools (2) DFN-CERT ftp://ftp.cert.dfn.de/pub/tools/ (3) Компьютерные средства безопасности и проверки COAST (Computer Operations, Audit, and Security Tools) coast.cs.purdue.edu:/pub/tools Важно заметить, что многие узлы, включая CERT и COAST, имеют зеркальные копии, разбросанные по Интернет. Будьте осторожны при использовании "хорошо известных" зеркальных узлов для копирования программ, а для проверки программ используйте средства верификации (контрольные суммы MD5 и т.д.). Умный атакер может рекламировать программы безопасности, которые были намеренно конструированы, так, чтобы обеспечить доступ к данным или системам. Программные средства COPS DES Drawbridge identd (не является на самом деле средством безопасности) ISS Kerberos logdaemon lsof MD5 PEM PGP rpcbind/portmapper замещение SATAN sfingerd S/KEY smrsh ssh swatch TCP-Wrapper tiger Tripwire* TROJAN.PL   8. Почтовые списки и другие ресурсы Было бы невозможно перечислить все почтовые подписные листы и другие ресурсы, имеющие отношения к безопасности. Однако ссылки, названные ниже, являются стартовыми точками, с которых читатель может начать. Все эти ссылки предназначены для клиентов ИНТЕРНЕТ. Некоторые специфические ресурсы (производители и географические адреса) могут быть найдены через представленные ниже ссылки. Почтовые подписные листы (1) Консультация CERT (TM) Посылайте почтовое сообщение по адресу: cert-advisory-request@cert.org. В теле сообщения надо написать: subscribe cert <FIRSTNAME> <LASTNAME>. Консультация CERT предоставляет информацию о том, как получить поправку (patch) к программе или подробности того, как обойти какую-то известную проблему безопасности. Координационный центр CERT работает с поставщиками, чтобы предоставлять нужные коррекции программ или методики для решения задач безопасности, и не публикует ничего об известных уязвимостях до тех пор, пока не будут найдены средства их защиты. Консультация CERT может также выдавать предупреждения клиентуре о возможных атаках (например, "CA-91:18.Active.Internet.tftp.Attacks"). Консультации CERT публикуются в группе новостей USENET: comp.security.announce.   Архивы консультации CERT доступны посредством анонимного FTP по адресу info.cert.org в каталоге /pub/cert_advisories. (2) VIRUSL-List Посылайте почтовое сообщение по адресу: listserv%lehiibm1.bitnet@mitvma.mit.edu Тело сообщения: subscribe virus-L FIRSTNAME LASTNAME VIRUS-L является почтовым подписным листом, работающим через посредника, и посвященным проблеме компьютерных вирусов. За дополнительной информацией рекомендуется обращаться к файлу "virus-l.README", доступному через анонимный FTP по адресу cs.ucr.edu. (3) Интернет Сетевые экраны. Посылайте почтовое сообщение по адресу: majordomo@greatcircle.com Тело сообщения: subscribe firewalls user@host Подписные листы по сетевым экранам являются дискуссионным форумом для администраторов и программистов. Группы новостей USENET (1) comp.security.announce Группа новостей comp.security.announce работает через посредника и используется только для рассылки рекомендаций CERT. (2) comp.security.misc comp.security.misc является форумом для обсуждения компьютерной безопасности, особенно если это относится к ОС UNIX(r). (3) alt.security Группа новостей alt.security является также форумом для обсуждения компьютерной безопасности, и других вопросов, таких как замки автомашин и охранные системы.   (4) comp.virus Группа новостей comp.virus работает через посредника и нацелена на компьютерные вирусы. Дополнительную информацию смотри в файле "virus-l.README", доступном через анонимный FTP по адресу info.cert.org в каталоге /pub/virus-l. (5) comp.risks Группа новостей comp.risks является форумом, работающим через посредника, посвященным рискам при работе с ЭВМ и смежным темам. Страницы World-Wide Web (1) http://www.first.org/ Ресурсы компьютерной безопасности Счетной палаты. Главное внимание уделено информации по преодолению кризисов, по угрозам безопасности, уязвимостям и решениям. В то же время, Счетная палата стремится предоставить общий индекс по компьютерной безопасности, включая риски, конфиденциальность, юридические вопросы, вирусы, страхование, политика и обучение. (2) http://www.telstra.com.au/info/security.html   Этот индекс ссылок содержит список ссылок на первоисточники по сетевой и компьютерной безопасности. Многие, если не все, программные средства работают хорошо, но мы не гарантируем этого. Эта информация предназначена для обучения и легального использования методик компьютерной безопасности. (3) http://www.alw.nih.gov/Security/security.html На этой странице представлена общая информация о компьютерной информации. Информация привязана к первоисточникам, а в каждом разделе данные организованы по темам. Последние модификации представлены на странице What's New. (4) http://csrc.ncsl.nist.gov Этот архив в Национальном Институте Стандартов и ресурсы технологии компьютерной безопасности Счетной палаты, страница содержит много уведомлений, программ и документов, относящихся к компьютерной безопасности. 9. Ссылки [Appelman, ppelman, et. al., 1995] Appelman, Heller, Ehrman, White, and McAuliffe, "The Law and The Internet", USENIX 1995 Technical Conference on UNIX and Advanced Computing, New Orleans, LA, January 16-20, 1995. [ABA, 1989] American Bar Association, Section of Science and Technology, "Guide to the Prosecution of Telecommunication Fraud by the Use of Computer Crime Statutes", American Bar Association, 1989. [Aucoin, 1989] R. Aucoin, "Computer Viruses: Checklist for Recovery", Computers in Libraries, Vol. 9, No. 2, Pg. 4, February 1989. [Barrett, 1996] D. Barrett, "Bandits on the Information Superhighway", O'Reilly & Associates, Sebastopol, CA, 1996. [Bates, 1992] R. Bates, "Disaster Recovery Planning: Networks, Telecommunications and Data Communications", McGraw-Hill, 1992. [Bellovin, 1989] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", Computer Communication Review, Vol 19, 2, pp. 32-48, April 1989. [Bellovin, 1990] S. Bellovin, and M. Merritt, "Limitations of the Kerberos Authentication System", Computer Communications Review, October 1990. [Bellovin, 1992] S. Bellovin, "There Be Dragon", USENIX: Proceedings of the Third Usenix Security Symposium, Baltimore, MD. September, 1992. [Bender, 1894] D. Bender, "Computer Law: Evidence and Procedure", M. Bender, New York, NY, 1978-present. [Bloombecker, 1990] B. Bloombecker, "Spectacular Computer Crimes", Dow Jones- Irwin, Homewood, IL. 1990. [Brand, 1990] R. Brand, "Coping with the Threat of Computer Security Incidents: A Primer from Prevention through Recovery", R. Brand, 8 June 1990. [Brock, 1989] J. Brock, "November 1988 Internet Computer Virus and the Vulnerability of National Telecommunications Networks to Computer Viruses", GAO/T-IMTEC-89-10, Washington, DC, 20 July 1989. [BS 7799] British Standard, BS Tech Cttee BSFD/12, Info. Sec. Mgmt, "BS 7799 : 1995 Code of Practice for Information Security Management", British Standards Institution, London, 54, Effective 15 February 1995. [Caelli, 1988] W. Caelli, Editor, "Computer Security in the Age of Information", Proceedings of the Fifth IFIP International Conference on Computer Security, IFIP/Sec '88. [Carroll, 1987] J. Carroll, "Computer Security", 2nd Edition, Butterworth Publishers, Stoneham, MA, 1987. [Cavazos, 1995] E. Cavazos and G. Morin, "Cyber-Space and The Law", MIT Press, Cambridge, MA, 1995. [CCH, 1989] Commerce Clearing House, "Guide to Computer Law", (Topical Law Reports), Chicago, IL., 1989. [Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet Filtering", USENIX: Proceedings of the Third UNIX Security Symposium, Baltimore, MD, September 1992. [Chapman, 1995] B. Chapman and E. Zwicky, "Building Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995. [Cheswick, 1990] B. Cheswick, "The Design of a Secure Internet Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA, June 1990. [Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker is Lured, Endured, and Studied", AT&T Bell Laboratories. [Cheswick, 1994] W. Cheswick and S. Bellovin, "Firewalls and Internet Security: Repelling the Wily Hacker", Addison-Wesley, Reading, MA, 1994. [Conly, 1989] C. Conly, "Organizing for Computer Crime Investigation and Prosecution", U.S. Dept. of Justice, Office of Justice Programs, Under Contract Number OJP-86-C-002, National Institute of Justice, Washington, DC, July 1989. [Cooper, 1989] J. Cooper, "Computer and Communications Security: Strategies for the 1990s", McGraw-Hill, 1989. [CPSR, 1989] Computer Professionals for Social Responsibility, "CPSR Statement on the Computer Virus", CPSR, Communications of the ACM, Vol. 32, No. 6, Pg. 699, June 1989. [CSC-STD-002-85, 1985] Department of Defense, "Password Management Guideline", CSC-STD-002-85, 12 April 1985 , 31 pages. [Curry, 1990] D. Curry, "Improving the Security of Your UNIX System", SRI International Report ITSTD-721-FR-90-21, April 1990. [Curry, 1992] D. Curry, "UNIX System Security: A Guide for Users and Systems Administrators", Addision-Wesley, Reading, MA, 1992. [DDN88] Defense Data Network, "BSD 4.2 and 4.3 Software Problem Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3 November 1988. [DDN89] DCA DDN Defense Communications System, "DDN Security Bulletin 03", DDN Security Coordination Center, 17 October 1989. [Denning, 1990] P. Denning, Editor, "Computers Under Attack: Intruders, Worms, and Viruses", ACM Press, 1990. [Eichin, 1989] M. Eichin, and J. Rochlis, "With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988", Massachusetts Institute of Technology, February 1989. [Eisenberg, et. al., 89] T. Eisenberg, D. Gries, J. Hartmanis, D. Holcomb, M. Lynn, and T. Santoro, "The Computer Worm", Cornell University, 6 February 1989. [Ermann, 1990] D. Ermann, M. Williams, and C. Gutierrez, Editors, "Computers, Ethics, and Society", Oxford University Press, NY, 1990. (376 pages, includes bibliographical references). [Farmer, 1990] D. Farmer and E. Spafford, "The COPS Security Checker System", Proceedings of the Summer 1990 USENIX Conference, Anaheim, CA, Pgs. 165-170, June 1990. [Farrow, 1991] Rik Farrow, "UNIX Systems Security", Addison-Wesley, Reading, MA, 1991. [Fenwick, 1985] W. Fenwick, Chair, "Computer Litigation, 1985: Trial Tactics and Techniques", Litigation Course Handbook Series No. 280, Prepared for distribution at the Computer Litigation, 1985: Trial Tactics and Techniques Program, February-March 1985. [Fites 1989] M. Fites, P. Kratz, and A. Brebner, "Control and Security of Computer Information Systems", Computer Science Press, 1989. [Fites, 1992] Fites, Johnson, and Kratz, "The Computer Virus Crisis", Van Hostrand Reinhold, 2nd edition, 1992. [Forester, 1990] T. Forester, and P. Morrison, "Computer Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990. [Foster, 1990] T. Forester, and P. Morrison, "Computer Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990. (192 pages including index.) [GAO/IMTEX-89-57, 1989] U.S. General Accounting Office, "Computer Security - Virus Highlights Need for Improved Internet Management", United States General Accounting Office, Washington, DC, 1989. [Garfinkel, 1991] S. Garfinkel, and E. Spafford, "Practical Unix Security", O'Reilly & Associates, ISBN 0-937175-72-2, May 1991. [Garfinkel, 1995] S. Garfinkel, "PGP:Pretty Good Privacy", O'Reilly & Associates, Sebastopol, CA, 1996. [Garfinkel, 1996] S. Garfinkel and E. Spafford, "Practical UNIX and Internet Security", O'Reilly & Associates, Sebastopol, CA, 1996. [Gemignani, 1989] M. Gemignani, "Viruses and Criminal Law", Communications of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989. [Goodell, 1996] J. Goodell, "The Cyberthief and the Samurai: The True Story of Kevin Mitnick-And The Man Who Hunted Him Down", Dell Publishing, 1996. [Gould, 1989] C. Gould, Editor, "The Information Web: Ethical and Social Implications of Computer Networking", Westview Press, Boulder, CO, 1989. [Greenia, 1989] M. Greenia, "Computer Security Information Sourcebook", Lexikon Services, Sacramento, CA, 1989. [Hafner, 1991] K. Hafner and J. Markoff, "Cyberpunk: Outlaws and Hackers on the Computer Frontier", Touchstone, Simon & Schuster, 1991. [Hess] D. Hess, D. Safford, and U. Pooch, "A Unix Network Protocol Security Study: Network Information Service", Texas A&M University. [Hoffman, 1990] L. Hoffman, "Rogue Programs: Viruses, Worms, and Trojan Horses", Van Nostrand Reinhold, NY, 1990. (384 pages, includes bibliographical references and index.) [Howard, 1995] G. Howard, "Introduction to Internet Security: From Basics to Beyond", Prima Publishing, Rocklin, CA, 1995. [Huband, 1986] F. Huband, and R. Shelton, Editors, "Protection of Computer Systems and Software: New Approaches for Combating Theft of Software and Unauthorized Intrusion", Papers presented at a workshop sponsored by the National Science Foundation, 1986. [Hughes, 1995] L. Hughes Jr., "Actually Useful Internet Security Techniques", New Riders Publishing, Indianapolis, IN, 1995. [IAB-RFC1087, 1989] Internet Activities Board, "Ethics and the Internet", RFC 1087, IAB, January 1989. Also appears in the Communications of the ACM, Vol. 32, No. 6, Pg. 710, June 1989. [Icove, 1995] D. Icove, K. Seger, and W. VonStorch, "Computer Crime: A Crimefighter's Handbook", O'Reilly & Associates, Sebastopol, CA, 1995. [IVPC, 1996] IVPC, "International Virus Prevention Conference '96 Proceedings", NCSA, 1996. [Johnson] D. Johnson, and J. Podesta, "Formulating A Company Policy on Access to and Use and Disclosure of Electronic Mail on Company Computer Systems". [Kane, 1994] P. Kane, "PC Security and Virus Protection Handbook: The Ongoing War Against Information Sabotage", M&T Books, 1994. [Kaufman, 1995] C. Kaufman, R. Perlman, and M. Speciner, "Network Security: PRIVATE Communication in a PUBLIC World", Prentice Hall, Englewood Cliffs, NJ, 1995. [Kent, 1990] S. Kent, "E-Mail Privacy for the Internet: New Software and Strict Registration Procedures will be Implemented this Year", Business Communications Review, Vol. 20, No. 1, Pg. 55, 1 January 1990. [Levy, 1984] S. Levy, "Hacker: Heroes of the Computer Revolution", Delta, 1984. [Lewis, 1996] S. Lewis, "Disaster Recovery Yellow Pages", The Systems Audit Group, 1996. [Littleman, 1996] J. Littleman, "The Fugitive Game: Online with Kevin Mitnick", Little, Brown, MA., 1996. [Lu, 1989] W. Lu and M. Sundareshan, "Secure Communication in Internet Environments: A Hierarchical Key Management Scheme for End-to-End Encryption", IEEE Transactions on Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989. [Lu, 1990] W. Lu and M. Sundareshan, "A Model for Multilevel Security in Computer Networks", IEEE Transactions on Software Engineering, Vol. 16, No. 6, Page 647, 1 June 1990. [Martin, 1989] M. Martin, and R. Schinzinger, "Ethics in Engineering", McGraw Hill, 2nd Edition, 1989. [Merkle] R. Merkle, "A Fast Software One Way Hash Function", Journal of Cryptology, Vol. 3, No. 1. [McEwen, 1989] J. McEwen, "Dedicated Computer Crime Units", Report Contributors: D. Fester and H. Nugent, Prepared for the National Institute of Justice, U.S. Department of Justice, by Institute for Law and Justice, Inc., under contract number OJP-85-C-006, Washington, DC, 1989. [MIT, 1989] Massachusetts Institute of Technology, "Teaching Students About Responsible Use of Computers", MIT, 1985-1986. Also reprinted in the Communications of the ACM, Vol. 32, No. 6, Pg. 704, Athena Project, MIT, June 1989. [Mogel, 1989] Mogul, J., "Simple and Flexible Datagram Access Controls for UNIX-based Gateways", Digital Western Research Laboratory Research Report 89/4, March 1989. [Muffett, 1992] A. Muffett, "Crack Version 4.1: A Sensible Password Checker for Unix" [NCSA1, 1995] NCSA, "NCSA Firewall Policy Guide", 1995. [NCSA2, 1995] NCSA, "NCSA's Corporate Computer Virus Prevention Policy Model", NCSA, 1995. [NCSA, 1996] NCSA, "Firewalls & Internet Security Conference '96 Proceedings", 1996. [NCSC-89-660-P, 1990] National Computer Security Center, "Guidelines for Formal Verification Systems", Shipping list no.: 89-660-P, The Center, Fort George G. Meade, MD, 1 April 1990. [NCSC-89-254-P, 1988] National Computer Security Center, "Glossary of Computer Security Terms", Shipping list no.: 89-254-P, The Center, Fort George G. Meade, MD, 21 October 1988. [NCSC-C1-001-89, 1989] Tinto, M., "Computer Viruses: Prevention, Detection, and Treatment", National Computer Security Center C1 Technical Report C1-001-89, June 1989.   [NCSC Conference, 1989] National Computer Security Conference, "12th National Computer Security Conference: Baltimore Convention Center, Baltimore, MD, 10-13 October, 1989: Information Systems Security, Solutions for Today - Concepts for Tomorrow", National Institute of Standards and National Computer Security Center, 1989. [NCSC-CSC-STD-003-85, 1985] Нational Computer Security Center, "Guidance for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments", CSC-STD-003-85, NCSC, 25 June 1985 [NCSC-STD-004-85, 1985] National Computer Security Center, "Technical Rationale Behind CSC-STD-003-85: Computer Security Requirements", CSC-STD-004-85, NCSC, 25 June 1985 [NCSC-STD-005-85, 1985] National Computer Security Center, "Magnetic Remanence Security Guideline", CSC-STD-005-85, NCSC, 15 November 1985 [NCSC-TCSEC, 1985] National Computer Security Center, "Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, CSC-STD-001-83, NCSC, December 1985. [NCSC-TG-003, 1987] NCSC, "A Guide to Understanding DISCRETIONARY ACCESS CONTROL in Trusted Systems", NCSC-TG-003, Version-1, 30 September 1987, 29 pages. [NCSC-TG-001, 1988] NCSC, "A Guide to Understanding AUDIT in Trusted Systems", NCSC-TG-001, Version-2, 1 June 1988, 25 pages. NCSC-TG-004, 1988] National Computer Security Center, "Glossary of Computer Security Terms", NCSC-TG-004, NCSC, 21 October 1988. [NCSC-TG-005, 1987] National Computer Security Center, "Trusted Network Interpretation", NCSC-TG-005, NCSC, 31 July 1987. [NCSC-TG-006, 1988] NCSC, "A Guide to Understanding CONFIGURATION MANAGEMENT in Trusted Systems", NCSC-TG-006, Version-1, 28 March 1988, 31 pages. [NCSC-TRUSIX, 1990] National Computer Security Center, "Trusted UNIX Working Group (TRUSIX) rationale for selecting access control list features for the UNIX system", Shipping list no.: 90-076-P, The Center, Fort George G. Meade, MD, 1990 [NRC, 1991] National Research Council, "Computers at Risk: Safe Computing in the Information Age", National Academy Press, 1991. [Nemeth, 1995] E. Nemeth, G. Snyder, S. Seebass, and T. Hein, "UNIX Systems Administration Handbook", Prentice Hall PTR, Englewood Cliffs, NJ, 2nd ed. 1995. [NIST, 1989] National Institute of Standards and Technology, "Computer Viruses and Related Threats: A Management Guide", NIST Special Publication 500-166, August 1989. [NSA] National Security Agency, "Information Systems Security Products and Services Catalog", NSA, Quarterly Publication. [NSF, 1988] National Science Foundation, "NSF Poses Code of Networking Ethics", Communications of the ACM, Vol. 32, No. 6, Pg. 688, June 1989. Also appears in the minutes of the regular meeting of the Division Advisory Panel for Networking and Communications Research and Infrastructure, Dave Farber, Chair, November 29-30, 1988. [NTISSAM, 1987] NTISS, "Advisory Memorandum on Office Automation Security Guideline", NTISSAM COMPUSEC/1-87, 16 January 1987, 58 pages. [OTA-CIT-310, 1987] United States Congress, Office of Technology Assessment, "Defending Secrets, Sharing Data: New Locks and Keys for Electronic Information", OTA-CIT-310, October 1987. [OTA-TCT-606] Congress of the United States, Office of Technology Assessment, "Information Security and Privacy in Network Environments", OTA-TCT-606, September 1994. [Palmer, 1989] I. Palmer, and G. Potter, "Computer Security Risk Management", Van Nostrand Reinhold, NY, 1989. [Parker, 1989] D. Parker, "Computer Crime: Criminal Justice Resource Manual", U.S. Dept. of Justice, National Institute of Justice, Office of Justice Programs, Under Contract Number OJP-86-C-002, Washington, D.C., August 1989. [Parker, 1990] D. Parker, S. Swope, and B. Baker, "Ethical Conflicts: Information and Computer Science, Technology and Business", QED Information Sciences, Inc., Wellesley, MA. (245 pages). [Pfleeger, 1989] C. Pfleeger, "Security in Computing", Prentice-Hall, Englewood Cliffs, NJ, 1989. [Quarterman, 1990] J. Quarterman, J., "The Matrix: Computer Networks and Conferencing Systems Worldwide", Digital Press, Bedford, MA, 1990. [Ranum1, 1992] M. Ranum, "An Internet Firewall", Proceedings of World Conference on Systems Management and Security, 1992. [Ranum2, 1992] M. Ranum, "A Network Firewall", Digital Equipment Corporation Washington Open Systems Resource Center , June 12, 1992. [Ranum, 1993] M. Ranum, "Thinking About Firewalls", 1993. [Ranum, 1994] M. Ranum and F. Avolio, "A Toolkit and Methods for Internet Firewalls", Trustest Information Systems, 1994. [Reinhardt, 1992] R. Reinhardt, "An Architectural Overview of UNIX Network Security" [Reinhardt, 1993] R. Reinhardt, "An Architectural Overview of UNIX Network Security", ARINC Research Corporation, February 18, 1993. [Reynolds-RFC1135, 1989] The Helminthiasis of the Internet, RFC 1135, USC/Information Sciences Institute, Marina del Rey, CA, December 1989 [Russell, 1991] D. Russell and G. Gangemi, "Computer Security Basics" O'Reilly & Associates, Sebastopol, CA, 1991. [Schneier 1996] B. Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", John Wiley & Sons, New York, second edition, 1996. [Seeley, 1989] D. Seeley, "A Tour of the Worm", Proceedings of 1989 Winter USENIX Conference, Usenix Association, San Diego, CA, February 1989. [Shaw, 1986] E. Shaw Jr., "Computer Fraud and Abuse Act of 1986", Congressional Record (3 June 1986), Washington, D.C., 3 June 1986. [Shimomura, 1996] T. Shimomura with J. Markoff, "Takedown:The Pursuit and Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw-by the Man Who Did It", Hyperion, 1996. [Shirey, 1990] R. Shirey, "Defense Data Network Security Architecture", Computer Communication Review, Vol. 20, No. 2, Page 66, 1 April 1990. [Slatalla, 1995] M. Slatalla and J. Quittner, "Masters of Deception: The Gang that Ruled Cyberspace", Harper Collins Publishers, 1995. [Smith, 1989] M. Smith, "Commonsense Computer Security: Your Practical Guide to Preventing Accidental and Deliberate Electronic Data Loss", McGraw-Hill, New York, NY, 1989. [Smith, 1995] D. Smith, "Forming an Incident Response Team", Sixth Annual Computer Security Incident Handling Workshop, Boston, MA, July 25-29, 1995. [Spafford, 1988] E. Spafford, "The Internet Worm Program: An Analysis", Computer Communication Review, Vol. 19, No. 1, ACM SIGCOM, January 1989. Also issued as Purdue CS Technical Report CSD-TR-823, 28 November 1988 [Spafford, 1989] G. Spafford, "An Analysis of the Internet Worm", Proceedings of the European Software Engineering Conference 1989, Warwick England, September 1989. Proceedings published by Springer-Verlag as: Lecture Notes in Computer Science #387. Also issued as Purdue Technical Report #CSD-TR-933 [Spafford, 1989] E. Spafford, K. Heaphy, and D. Ferbrache, "Computer Viruses: Dealing with Electronic Vandalism and Programmed Threats", ADAPSO, 1989. (109 pages.) [Stallings1, 1995] W. Stallings, "Internet Security Handbook", IDG Books, Foster City CA, 1995. [Stallings2, 1995] W. Stallings, "Network and Internetwork Security", Prentice Hall, , 1995. [Stallings3, 1995] W. Stallings, "Protect Your Privacy: A Guide for PGP Users" PTR Prentice Hall, 1995. [Stoll, 1988] C. Stoll, "Stalking the Wily Hacker", Communications of the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM, New York, NY, May 1988. [Stoll, 1989] C. Stoll, "The Cuckoo's Egg", ISBN 00385-24946-2, Doubleday, 1989. [Treese, 1993] G. Treese and A. Wolman, "X Through the Firewall, and Other Applications Relays", Digital Equipment Corporation, Cambridge Research Laboratory, CRL 93/10, May 3, 1993. [Trible, 1986] P. Trible, "The Computer Fraud and Abuse Act of 1986", U.S. Senate Committee on the Judiciary, 1986. [Venema] W. Venema, "TCP WRAPPER: Network monitoring, access control, and booby traps", Mathematics and Computing Science, Eindhoven University of Technology, The Netherlands. USENIX, 1988] USENIX, "USENIX Proceedings: UNIX Security Workshop", Portland, OR, August 29-30, 1988. [USENIX, 1990] USENIX, "USENIX Proceedings:UNIX Security II Workshop", Portland, OR, August 27-28, 1990. [USENIX, 1992] USENIX, "USENIX Symposium Proceedings: UNIX Security III", Baltimore, MD, September 14-16, 1992. [USENIX, 1993] USENIX, "USENIX Symposium Proceedings: UNIX Security IV", Santa Clara, CA, October 4-6, 1993. [USENIX, 1995] USENIX, "The Fifth USENIX UNIX Security Symposium", Salt Lake City, UT, June 5-7, 1995. [Wood, 1987] C. Wood, W. Banks, S. Guarro, A. Garcia, V. Hampel, and H. Sartorio, "Computer Security: A Comprehensive Controls Checklist", John Wiley and Sons, Interscience Publication, 1987. [Wrobel, 1993] L. Wrobel, "Writing Disaster Recovery Plans for Telecommunications Networks and LANS", Artech House, 1993. [Vallabhaneni, 1989] S. Vallabhaneni, "Auditing Computer Security: A Manual with Case Studies", Wiley, New York, NY, 1989. Читайте также: SelectorNews        быстрая навигация по порталу   <СПРАВОЧНИК ПО БЕЗОПАСНОСТИ>

Реклама: