Криптоалгоритмы / 6_11_ Справочник по безопасности сетевого узла

6.11. Справочник по безопасности сетевого узла 2004 г. Назад: 6.10. Идентификатор доступа к сети

Оглавление: Телекоммуникационные технологии

Вперёд: 6.12. Фильтрация на входе сети: Отражение атак DoS, которые используют подмену IP-адреса отправителя (RFC-2827) 6.11. Справочник по безопасности сетевого узлаСемёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru @font-face { font-family: Helvetica; } @font-face { font-family: Courier; } @font-face { font-family: Helv; } @font-face { font-family: System; } @font-face { font-family: Wingdings; } @font-face { font-family: MS Gothic; } @font-face { font-family: Tahoma; } @font-face { font-family: @MS Mincho; } @page Section1 {size: 595.3pt 841.9pt; margin: 2.0cm 68.05pt 2.0cm 68.05pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } P.MsoFooter { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoFooter { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoFooter { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P.MsoPlainText { FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New" } LI.MsoPlainText { FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New" } DIV.MsoPlainText { FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New" } INS { TEXT-DECORATION: none } SPAN.msoDel { COLOR: red; TEXT-DECORATION: line-through } DIV.Section1 { page: Section1 } OL { MARGIN-BOTTOM: 0cm } UL { MARGIN-BOTTOM: 0cm } (RFC-2196, B. Fraser, сентябрь 1997) 1.  Введение Этот документ предоставляет собой руководство для системных и сетевых администраторов в сфере определения безопасной работы в условиях подключения к Интернет. Он построен на основе RFC-1244 и является результатом коллективного труда большого коллектива авторов. Среди них: Jules P. Aronson (aronson@nlm.nih.gov), Nevil Brownlee (http://zeus.sai.msu.ru:7000/nets/semenov/6/n.brownlee@auckland.ac.nz), Frank Byrum (byrum@norfolk.infi.net), Joao Nuno Ferreira (http://zeus.sai.msu.ru:7000/nets/semenov/6/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] и включает в себя следующие шаги: (1)  Определение того, что вы пытаетесь защитить. (2)  Выявление того, от чего вы пытаетесь защититься. (3)  Выявление того, откуда и какие исходят угрозы. (4)  Осуществление мер, которые должны защитить ваши данные и систему эффективным образом. (5)  Постоянное отслеживание процесса и внесение улучшений всякий раз, когда обнаруживаются слабости. Большая часть данного документа концентрируется на пункте 4, но и другие пункты не могут игнорироваться, если в вашем узле необходимо реализовать эффективный план безопасности. Общеизвестно, что цена обеспечения безопасности должна быть ниже, чем стоимость восстановления после разрушения системы. Стоимость в данном контексте должна включать в себя денежные издержки, потери доверия и репутации и, возможно, какие-то менее очевидные моменты. Без разумного осознания того, что вы должны защитить и откуда и какие исходят угрозы, следование этому правилу может быть затруднительным. 1.6  Оценка риска 1.6.1  Общее обсуждение Одной из наиболее важных причин разработки политики компьютерной безопасности является гарантия того, что усилия, потраченные, на достижение безопасности принесут выгоды, превосходящие затраты. Хотя это может показаться очевидным, возможны заблуждения относительно того, на чем следует сконцентрировать усилия. Например, существует много данных и публикаций о хакерах, атакующих компьютерные системы издали, в то время как большинство нарушений безопасности в подавляющем числе организаций возникает по вине своих сотрудников. Анализ риска включает в себя определение того, что вам надо защитить, от чего и как. Это процесс рассмотрения всех рисков, а не аранжировка этих рисков по уровню угрозы. Этот процесс включает в себя принятие эффективных в стоимостном отношении решений, связанных с защитой нужных объектов. Полный анализ рисков находится за пределами задач данного документа. [Fites 1989] и [Pfleeger 1989] рассмотрели некоторые подходы к данной теме. Однако имеется два пункта анализа риска, которые будут кратко рассмотрены в последующих секциях: (1) Идентификация защищаемых объектов (2) Идентификация угроз Для каждого из защищаемых объектов, основными целями безопасности являются доступность, конфиденциальность и целостность. Каждая угроза должна рассматриваться с точки зрения ее влияния на эти области. 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  Подготовка и планирование обработки инцидентов Часть мер в случае инцидента должна быть подготовлена до того, как инцидент произойдет в первый раз. Это включает установку приемлемого уровня защиты, как