Справочник по безопасности сетевого узла


Зам. зав. кафедры "Телекоммуникационные сети и системы" МФТИ
Зам.зав. кафедры Информатики ФНТИ МФТИ
Нач. лаб. Инфокоммуникационных технологий
Института Теоретической и Экспериментальной Физики

(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., услуги, преднамеренно сделанные доступными для пользователей за пределами узла) будут, вообще говоря, иметь требования безопасности, которые существенно отличаются. Следовательно, разумно ограничить внутренние услуги набором ЭВМ, подклОбновлено: 11.03.2015