Мельников Д. А. - Организация и обеспечение безопасности информационно-технологических сетей и систем - 2012

Третья проблема - финансовая. Значимость и острота этой проблемы полностью зависят от какой-либо конкретной системы. Однако чрезвычайно важно дать количественную оценку тем или иным принимаемым решениям в смысле финансовых затрат, необ­ ходимых либо для приобретения, либо для внедрения системы за­ щиты. Создание корпоративной СОИБ является хорошим делом, однако, очень важно иметь в виду, что создавать СОИБ необходимо так, что бы она не требовала потом к себе постоянного (и главное дорогостоящего) внимания. Другими словами, очень важно оценить не только затраты, связанные с приобретением и установкой СЭ, но

изатраты, связанные с его последующей текущей эксплуатацией.

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

Таким образом, необходимо принять один из вариантов решения:

1)либо использовать «пустой» сервер, который будет разме­ щаться за пределами корпоративной ИТС и выполнять функции уполномоченного сервера одной из прикладных служб, например TELNET, FTP, NNTP и др.;

2)либо настроить граничный маршрутизатор как фильтр IP-пакетов, разрешающий установление соединений с одним

или несколькими корпоративными (внутренними) 1Р-узлами. Каждый вариант решения имеет свои преимущества и недос­ татки. Например, уполномоченный сервер прикладной службы, с одной стороны, обеспечивает более высокий уровень контроля тра­ фика и, возможно, уровень защищенности «в обмен» на более высо­ кие затраты, необходимые для настройки системы, но, с другой сто­ роны, снижает качество обслуживания, который может быть, в принципе, достигнут (так как для каждой прикладной службы не­ обходим свой уполномоченный сервер). Каждый раз традиционный выбор между простотой в использовании и уровнем защищенности заставляет нас основательно подумать о возможных последствиях

принятия того или иного решения, в полном смысле этого слова.

Основные типы сетевых экранов. Концептуально, различают три типа СЭ:

1)сетевого уровня (СЭс);

2)прикладного уровня (СЭп);

3)гибридный вариант (СЭг).

На первый взгляд, различия между типами СЭ вполне очевид­ ны, однако, современные разработки в области СЭ скрывают их раз­ личия, и поэтому трудно определить какой из них «лучше» или «хуже». Тем не менее, необходимо быть очень внимательным при выборе того или иного типа СЭ, основываясь при этом на собствен­ ных требованиях, которым удовлетворяет СЭ.

Всущности, все зависит от того, какой способ (протокол) достав­ китрафика из одной защищенной зоны в другую используется в СЭ.

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

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

Сетевые экраны 1Р(сетевого)-уровня. Такие СЭ представляют

программные модули, которые принимают решение на основе анали­ за IP-адресов и номеров транспортных портов отправите­ ля/получателя сообщения, содержащихся в определенных IP-пакетах. Простой маршрутизатор представляет собой традиционный СЭс, так как он не способен принимать сложных решений относительно «содержимого» и реального источника поступившего IP-пакета. Со­ временные СЭс стали чрезвычайно сложными и в настоящее время обрабатывают информацию о состоянии проходящих через них ло­ гических (виртуальных) соединений, а также содержание некоторых потоков данных и др. Существует одно функциональное свойство, которым обладают многие СЭс, а именно, они маршрутизируют проходящий через них трафик, и поэтому при использовании таких СЭс необходимо, либо иметь официально зарегистрированный на- °ор IP-адресов, либо использовать набор IP-адресов, выделенный Для корпоративных сетей. СЭс становятся очень быстродействую­ щими и очень прозрачными для пользователей.

Рис. 22.1. Маршрутизатор/СЭ с выделенным 1Р-узло^бастионом

На рис. 22.1 представлен СЭс, именуемый как «СЭ с выделенным IP-узлом/бастионом» («Screened Host Firewall»). В случае использова­ ния маршрутизатора с функциями заградительного СЭ (маршрутиза­ тор/ СЭ) совместно с выделенным IP-узлом/бастионом, маршрутиза­ тор функционирует на сетевом уровне и предоставляет (с помощью собственных средств) доступ только к одному специально выделенно­ му IP-узлу, именуемому бастионом. Такое системное решение позволя­ ет защитить корпоративную сеть от многих видов атак.

На рис. 22.2 представлен другой пример СЭс, который называет­ ся «СЭ с промежуточным IP-узлом/ бастионом и корпоративным мар­ шрутизатором» («Screened Subnet Firewall»). В случае использования маршрутизатора/СЭ совместно с промежуточным IP-узлом/бас­ тионом и корпоративным маршрутизатором, маршрутизатор/СЭ функционирует на сетевом уровне и предоставляет (с помощью собственных средств) доступ ко всей корпоративной сети через IP-узел/бастион и корпоративный маршрутизатор. Это системное решение напоминает предыдущее, однако, оно эффективнее, так как за IP-узлом/бастионом стоит корпоративный маршрутизатор, обеспечивающий дополнительный контроль входящего и исходя­ щего трафика.

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

в корпоративную сеть. СЭп могут использоваться в качестве транс­ ляторов сетевых IP-адресов, так как трафик поступает на одну сто­ рону СЭп и выходит с другой его стороны, при этом трафик прохо­ дит обработку в прикладном модуле, который позволяет эффек­ тивно «замаскировать» реальный объект, инициировавший соеди­ нение. Используя, таким образом, прикладной модуль, в некоторых случаях можно добиться, чтобы СЭп был более быстродействую­ щим и менее прозрачным. Более ранние СЭп не были достаточно прозрачны для оконечных пользователей и иногда требовали до­ полнительных настроек и «обучения». Современные СЭп очень час­ то бывают полностью прозрачными. СЭп способны проводить более детальные проверки транслируемого через них трафика, а также они позволяют создавать более жесткие модели безопасности по сравнению с СЭс.

На рис. 22.3 представлен СЭп, называемый «двухадресный шлюз безопасности» («Dual Homed Gateway»). Такой СЭп представ­ ляет собой хорошо защищенный IP-узел, выступающий в роли уполномоченного прикладного сервера, т.е. в его составе функцио­ нирует прикладной программный модуль, который блокирует весь проходящий через него трафик. Двухадресный СЭп имеет два сете­ вых интерфейса: первый для внешней сети (Internet), второй для корпоративной сети.

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

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

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

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

В сильно нагруженных системах, модули памяти имеют перво­ степенную важность. Необходимо иметь достаточный объем опера­ тивной памяти (RAM), чтобы обслужить каждое требование каждого программного модуля, которые необходимы для нормального функ­ ционирования системы. В противном случае, процесс «подкачки» данных в оперативную память может привести к снижению произво­ дительности и, в конечном счете, к блокировке системы. Если процесс подкачки данных не является обременительным, то тогда, как прави­ ло, проблем не возникает, а вот если это процесс приводит к перегруз­ ке системы, то тогда стоит вопрос об увеличении оперативной памяти. Система, которая подвержена перегрузкам оперативной памяти, очень часто становится объектом атак типа «отказ в обслуживании» («denial- of-service»), или она просто начинает не успевать обрабатывать данные

вмасштабе реального времени. А это приводит к большим задержкам

инеобходимости перезагрузки системы.

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

Понятие «демилитаризованная зона». Демилитаризованная зона имеет аббревиатуру «DMZ» (demilitarized zone). С точки зрения СЭ, DMZ означает часть сети, которая не является ни частью корпо­ ративной сети, ни непосредственной частью Internet-сети. Обычно, это сетевой сегмент между маршрутизатором доступа в Internet-сеть и корпоративным IP-узлом/бастионом, хотя он может быть между двумя любыми сетевыми компонентами, реализующими политику безопасности в рамках архитектуры корпоративной сети.

DMZ может быть сформирована путём размещения списка управления доступом в корпоративном маршрутизаторе доступа. Такой подход позволяет минимизировать число корпоративных IP-узлов, которые необходимо «показывать» во внешней сети. При этом определяются контролируемые прикладные службы, про­ граммные модули которых размещаются в этих «показываемых» IP-узлах, а последние будут доступны для IP-узлов, размещенных в Internet-сети. Обычно, при использовании многих коммерческих СЭ-систем на корпоративном IP-узле/бастионе создается третий внешний интерфейс, который маркируется как DMZ. Этот третий интерфейс является точкой подключения сетевого сегмента, кото­ рый не является ни «внутренним», ни «внешним».

Например, W3-cepBep на основе операционной системы «Windows-NT» может быть уязвим к нескольким вариантам атак ти­ па «отказ в обслуживании», среди которых атаки с использованием специализированных служб SMB1 (Server Message Block), RPC (Re­ mote Procedure Call - услуга «вызов удаленной процедуры») и Net­ BIOS (Network Basic Input/Output System - сетевая базовая система ввода/вывода). Эти службы не нужны при функционировании W3-cepBepa, и поэтому при блокировании TCP-портов с номерами 135, 137,138 и 139 на IP-узле можно резко уменьшить число возмож­ ных вариантов атак типа «отказ в обслуживании». Фактически, если блокировать любой трафик на этом IP-узле, кроме НТТР-трафика,

1 Протокол уровня представления данных, обеспечивает информацион­

ный обмен по соединению «клиент-сервер» («запрос-ответ»). Он представ­ ляет собой набор команд для передачи файлов между компьютерами с различными операционными системами и между компьютерами и сете­ выми принтерами. Разработан Microsoft, Intel и IBM.

то тогда нарушитель будет способен атаковать только одну при­ кладную службу.

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

Как можно усилить безопасность «демилитаризованной зо­ ны»? Как правило, нарушитель «взламывает» тот IP-узел, который наиболее уязвим для нападения, и поэтому нарушитель устанавли­ вает «доверительные» связи между уязвимым IP-узлом и другими интересующими нарушителя сетевыми объектами.

Если в корпоративной DMZ функционирует несколько спе­ циализированных служб, которые имеют различные уровни защи­ щенности, то тогда можно принять решения о разбиении DMZ на несколько «субзон безопасности». Это можно реализовать путём создания нескольких субсетей в DMZ. Например, маршрутизатор доступа в DMZ может обслуживать две Ethernet-сети, защищённые с помощью ACL-организации доступа (Access Control List - перечень управления доступа).

Одна из двух Ethernet-сетей может использоваться клиентами корпоративной ИТС для обеспечения связи с информационными ресурсами и объектами глобальной Internet-сети. IP-узлы этой Ethernet-сети могут использоваться для ретрансляции, например, сообщений электронной почтовой службы, сетевой службы ново­ стей и DNS-сообщений. Другая Ethernet-сеть может включать кор­ поративный W3-cepBep и другие IP-узлы, которые будут обслужи­ вать запросы внешних пользователей глобальной Internet-сети.

Во многих организациях, службы, которые предназначены для запросов внешних пользователей глобальной Internet-сети, как пра­ вило, имеют не высокую защищенность, так как на безопасность та­ ких служб обращается мало внимания. (Например, если имеет место W 3-cepBep, то тогда неавторизованные и ненадежные пользователи могут активизировать CGI-интерфейс, РНР (Personal Home Page) и другие «нежелательные» программы. Такая ситуация может быть вполне приемлема для W3-cepBepa, но влечет за собой определен­ ный набор рисков и угроз, которые должны находиться под контро­ лем. Вероятно, такие службы являются источником большого коли­ чества проблем безопасности, если организация будет размещать программные модули этих служб в IP-узле/бастионе, так как любая ошибка в настройках и при обслуживании этого узла может привес­ тик коллапсу всей системы обеспечения ИБ.)

Путём кластеризации IP-узлов с одинаковыми уровнями риска в разных субсегментах DMZ можно минимизировать отрицательный

кой системе маршрутизатор/СЭ запрещает сквозную трансляцию Internet-трафика по всем возможным маршрутам в корпоративную (внутреннюю) сеть. Однако если не распространить это функцио­ нальное правило и на другие используемые программные средства безопасности, размещенные в IP-узле/бастионе и/или корпоратив­ ном маршрутизаторе (маршрутизатор с «заглушкой»), то тогда для получения неавторизованного доступа в корпоративную сеть пона­ добиться взломать (или скомпрометировать) только один компо­ нент структуры СЭ (т.е. маршрутизатор/СЭ). Но с другой стороны, если указанное функциональное правило включить в программные средства безопасности, размещенные в IP-узле/бастионе и корпора­ тивном маршрутизаторе, то тогда нарушителю понадобиться «взламывать» все три компонента СЭ-структуры.

Более того, если IP-узел/бастион или корпоративный маршру­ тизатор будут содержать это правило для блокировки внешнего дос­ тупа во внутреннюю (корпоративную) сеть, то тогда это позволит ис­ пользовать один из этих компонентов в качестве аварийной сигнали­ зации, которая при своем срабатывании укажет на несанкциониро­ ванное проникновение нарушителя через маршрутизатор/СЭ.

Блокировка ненужного («плохого») трафика. Там где СЭ, прежде всего, служит в интересах безопасности, а не в интересах связности, то тогда целесообразно, чтобы все «не нужные» службы («не нужный» трафик) блокировались в режиме «по умолчанию», и только специально выделенные службы, которые необходимы на регулярной основе, не должны блокироваться.

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

Прежде чем включить ту или иную службу в перечень особо «охраняемых», необходимо ответить на следующие вопросы:

1.Является ли протокол, используемый в этой службе, «хорошо известным» опубликованным в открытой печати протоколом?

2.Существует ли прикладной программный модуль (приклад­ ное программное обеспечение) для обслуживания этого про­ токола, и если да, то каковы результаты его открытого внедре­ ния и практического использования?

3.Насколько хорошо известна та или иная служба, а также при­ кладное программное обеспечение, реализующее эту службу?

4.Как будет влиять используемая служба на функциональную структуру (архитектуру) СЭ-системы; сможет ли нарушитель «видеть» компоненты СЭ-системы; сможет эксплуатируемая