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

служба «проникнуть» во внутренний сегмент корпоративной сети или повлечь за собой изменения в программных модулях IP-узлов, расположенных в DMZ?

Когда ответы на поставленные вопросы получены, то тогда не­ обходимо иметь в виду следующее:

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

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

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

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

Блокировка сообщений ненужных («плохих») W 3-cepBepOB.

Некоторое время назад «родилась» идея, что необходимо блокиро­ вать сообщения «плохих» W 3-ce p B e p oB , т.е. содержащие данные (ма­ териалы), которые отнесены организацией к категории «неумест­ ные» («ненужные»). Эта идея стала чрезвычайно популярной, но прежде чем реализовывать эту идею в функциональном процессе корпоративного СЭ необходимо учитывать следующее:

оне возможно на практике блокировать все, что отнесено орга­ низацией к категории «неуместные». В Internet-сети полно всякого рода информации. Блокировка только одного источ­ ника будет только перенаправлять трафик на другой источ­ ник такой «неуместной» информации, или станет причиной того, что нарушитель будет искать обходной путь;

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

лучателем сообщения. Фактически, сам IP-пакет «говорит» только то, куда он «хочет быть доставлен» (IP-адрес получателя), и ничего «не говорит» о том, как «желает туда попасть».

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

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

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

шрутизатор передает в ответ 1СМР/redirect-пакет, который сообща­ ет IP-узлу, что он должен выбрать правильный (другой) маршрут. Если нарушитель способен подделывать 1СМР/redirect-пакеты и ес­ ли IP-узел, который является целью атаки, реагирует на такие паке­ ты, то тогда нарушитель может внести изменения в маршрутную таблицу этого IP-узла и тем самым, скорее всего, нарушить его безо­ пасность путем перенаправления трафика по такому маршруту, ко­ торый не находится под контролем со стороны сетевого админист­ ратора. 1СМР/redirect-пакеты могут применяться нарушителем для проведения атаки типа «отказ в обслуживании». В таких случаях на IP-узел передается 1СМР/redirect-пакет, указывающий маршрут, ко­ торый не обеспечивает связность с этим IP-узлом, или передается другой ICMP/network/unreachable-пакет1, указывающий на то, что доступ в сеть назначения невозможен.

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

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

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

1Network Unreachable - сетевой сегмент, в который передается IP-пакет, не Достижим.

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

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

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

Захват SMTP-сервера (неавторизованная ретрансляция сообщений).

Захват SMTP-сервера происходит там, где «спаммер12« способен сге­ нерировать тысячи копий сообщений и разослать их по огромному количеству почтовых адресов. Так как такие списки почтовых адре­ сов очень часто бывают весьма скверными, а сами спаммеры пресле­ дуют целью снижение скорости функционирования почтового сер­ вера, многие из них используют простую передачу всего содержи­ мого их почтовых ящиков на SMTP-сервер, который будет пытаться разослать все поступившие почтовые сообщения.

1«Upstream» - направление трафика «пользователь -* ISP-сервер»; «Downstream» - направление трафика «ISP-сервер -► пользователь».

2«Spam» - «непрошенное» рекламное сообщение, сетевой мусор, мусорная почта, рассылаемые по электронной почте в личные почтовые ящики или телеконференции. Рассылка спама (спамминг - «spamming») считается на­ рушением этикета и правил применения компьютерных сетей, а тот, кю рассылает (спаммер - «spammer») - нарушителем.

сегмент имеет свою собственную стратегию обеспечения ИБ, кото­ рая определяет что необходимо, а что не нужно. При этом следует помнить, что основной частью работы при построении «сторожапривратника» организации (gatekeeper) является обучение. Корпо­ ративные пользователи хотят слишком много, начиная от цифрово­ го телевидения, видео программ, ведения переговоров в масштабе реального времени и кончая интерактивными базами данных, рас­ положенными внутри корпоративной сети.

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

HTTP-трафик и СЭ-система. Существуют три способа транс­ ляции HTTP-трафика через СЭ-систему:

1)разрешить формирование виртуальных соединений через маршрутизатор, если в СЭ-системе используются экранирую­ щие маршрутизаторы;

2)использовать клиентские программные W3-MOflynn, которые реализуют SOCKS-протокол1, и встроить программный SOCKS-модуль в качестве уполномоченного («proxy») SOCKSсервера в программное обеспечение IP-узла/бастиона;

3)встроить в программное обеспечение IP-узла/бастиона какойлибо W 3-cepBep, который способен выполнять функции упол­ номоченного \У3-сервера. В настоящее время существует много коммерческих программных продуктов, которые включают функцию уполномоченного сервера в интересах различных прикладных служб (FTP, GOPHER и др.).

SSL-трафик и СЭ-система. Протокол шлюза безопасности (Se­ cure Socket Layer - SSL12) занимает промежуточное положение (подуро­ вень) между протоколами транспортного и прикладного уровней и

1Этот протокол определен в стандартах RFC-1928, RFC-1929 и RFC-1961. Сам SOCKS-протокол определяет процедурную и логическую характери­ стики уполномоченного SOCKS-сервера.

2Протокол SSL был разработан фирмой Netscape, как протокол обеспечи­ вающий защиту сообщений протоколов прикладного уровня. Стандарт SSL включает также описание интерфейса для взаимодействия с приклад­ ными протоколами.

обеспечивает защиту сеансов связи (виртуальных соединений) органи­ зуемых через Internet-сеть. Первоначально, SSL-протокол был разрабо­ тан для защиты HTTP-трафика (так называемый HTTPS-протокол). Однако в настоящее время он может использоваться совместно и с дру­ гими прикладными протоколами (например, TELNET).

Чтобы транслировать SSL-трафик через СЭ-систему, необхо­ димо выполнить аналогичные операции, которые проводились для трансляции HTTP-трафика, если, конечно, SSL-трафик представля­ ет собой HTTP-трафик, прошедший обработку в соответствии SSLпротоколом. Существует только одно отличие: для организации так называемого SSL-туннеля необходима кэш-память, в которой бы хранились параметры этого SSL-туннеля. В настоящее время боль­ шинство коммерческих программных \У3-модулей имеют такую функцию «кэширования».

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

Сокрытие DNS-имен является одним из многих и весьма по­ лезных способов, используемым организацией, которая желает сде­ лать недоступными DNS-имена своих корпоративных IP-узлов для объектов Internet-сети. Успех такого способа основан на том, что DNS-клиенты, встроенные в программное обеспечение IP-узла, не Должны обращаться к DNS-серверу, встроенному в программное обеспечение того же IP-узла. Другими словами, в том, что DNS-

1Address Resolution Protocol (RFC-826) - протокол назначения сетевого ад­

реса новому компьютеру.

420 Глава 22. Проблемы функционирования сетевых экранов в Internet

сервер расположен в этом же IP-узле, где расположен DNS-клиент, нет ничего плохого, а именно с точки зрения перенаправления DNS-запроса (а также с точки зрения других преимуществ), который передает DNS-клиент на DNS-сервер, встроенный в программное обеспечение другого 1Р-узла.

Во-первых, DNS-сервер должен размещаться в программном обеспечении IP-узла/бастиона, чтобы к нему мог обращаться «внешний мир». Этот DNS-сервер должен быть настроен так, что бы он был доверенным для субсегментов (DNS-субзон) корпоративной сети. Фактически, все, что знает этот сервер, относится к тем дан­ ным, которые, в принципе, должны знать внешние Internet-объекты, а именно DNS-имена и адреса корпоративных IP-узлов/шлюзов, корпоративные RR-записи типа «МХ» с символами замещения1 («wildcard») и др. Это DNS-сервер общего пользования.

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

Все программные модули, реализующие функции DNS-клиента, которые встроены в программное обеспечение одного IP-узла со­ вместно с программным модулем DNS-сервера общего пользования, должны быть настроены так, чтобы они обращались к корпоратив­ ному DNS-серверу. Это главный принцип.

Внутренний DNS-клиент, запрашивающий информацию о внутреннем IP-узле, будет обращаться к внутреннему DNS-серверу и получит от него ответ. Если внутренний DNS-клиент запрашивает информацию о внешнем IP-узле, то тогда он будет обращаться к внутреннему DNS-серверу, который, в свою очередь, будет обра­ щаться к DNS-серверу общего пользования, который, в свою оче­ редь, запросит Internet-сеть. Ответ, переданный из Internet-сети, по­ ступит на DNS-сервер общего пользования, далее - на внутренний DNS-сервер, и потом его получит внутренний DNS-клиент. DNSклиент, расположенный на DNS-сервере общего пользования функ­

1 Resource Records (RR, RFC-1034) - записи источника данных. Тип «МХ>ч (Mail Exchange) - обмен сообщениями электронной почты.

ционирует по такому же алгоритму. Если внешний DNS-клиент за­ прашивает информацию о внутреннем IP-узле, то тогда он получит «запрещающий» ответ DNS-сервера общего пользования.

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

При решении проблемы определения DNS-имени корпора­ тивного сегмента можно использовать и другой весьма полезный прием, а именно использовать RR-записи типа «PTR» с символами замещения («wildcard»), размещенные в корпоративных DNSсубсегментах DNS-сегмента «IN-ADDR.ARPA»1. Запрос таких запи­ сей (т.е. получение корпоративных DNS-имен на основе IP-адресов) повлечет за собой поиск всех корпоративных (не общего пользова­ ния) IP-узлов, а в ответ, скорее всего, будет получена запись типа «unknown.YOUR.DOMAIN» (т.е. DNS-имя корпоративного сегмента), а не сообщение об ошибке. Это очень напоминает анонимные («anonymous») FTP-серверы (например, «ftp.uu.net»), так как они «настойчиво требуют получение» DNS-имен тех компьютеров, с ко­ торыми ведут информационный обмен. Однако такой способ может «потерпеть неудачу» в том случае, когда взаимодействующие между собой серверы проводят встречную DNS-проверку, при которой DNS-имя IP-узла сравнивается с его IP-адресом или наоборот.

FTP-трафик и СЭ-система. В целом, трансляцию FTP-трафика через СЭ-систему можно осуществить двумя способами:

виспользуя уполномоченный FTP-сервер;

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

1Назначение этого сегмента заключается в обеспечении гарантированного метода преобразования IP-адресов серверов в их DNS-имена, а также для Упрощения («облегчения») процедуры передачи запросов о размещении Всех шлюзов в соответствующей подсети в Internet.