Конфигурирование Firewall

48.1

Конфигурирование Firewall

Содержание

3.Решения ООО “Конфидент” для типового проекта системы

48.2

Конфигурирование Firewall

1. Проблемы выбора технологии Stateful Inspection или рroxy

Сущность технологии Stateful Inspection заключается в следующем: модуль инспекции анализирует данные, полу ченные от всех уровней коммуникаций. Эти данные о “состоянии” и “контексте” запоминаются и обновляются ди намически, обеспечивая виртуальную информацию о сессии для отслеживания протоколов без установки соеди нений (таких, как RPC и приложений, основанных на UDP). Данные, полученные из состояний соединений и при ложений, конфигурации сети и правил безопасности, используются для генерации соответствующего действия и либо принятия, либо отвержения, либо шифрации канала связи. Любой трафик, который явным образом не раз решен правилами безопасности, блокируется по умолчанию и одновременно в реальном времени генерируются сигналы оповещения, предоставляя системному администратору полную информацию о состоянии сети.

В технологии Stateful Inspection применяются специальные таблицы, с помощью которых отслеживаются со стояния каждого соединения и команды прикладного уровня и соответственно регулируется трафик. Проверка на основе таблиц осуществляется до начала взаимодействия данных с ОС firewall системы, при этом содер жащаяся в заголовках пакетов первичная информация передается через firewall систему неизмененной, если это разрешено установленной политикой безопасности.

Proxy службы разрешают только те службы, для которых есть proxy. Другими словами, если прикладной шлюз содержит proxy для FTP и TELNET, то в защищаемой подсети будут разрешены только FTP и TELNET, а другие службы будут полностью блокированы. Для некоторых организаций такой вид безопасности важен, так как гарантирует, что только те службы, которые считаются безопасными, будут пропускаться через межсетевой экран. Этот подход также предохраняет от возможности разработки новых небезопасных служб без уведом ления администраторов межсетевого экрана.

Другим преимуществом использования proxy служб является то, что может быть осуществлена фильтрация протоколов. Например, некоторые межсетевые экраны могут фильтровать ftp соединения и запрещать исполь зование команды FTP put, что было бы полезно для получения гарантий того, что пользователи не могут, на пример, писать на анонимный FTP сервер.

Сторонники proxy технологии утверждают, что она гарантирует более высокий уровень безопасности, посколь ку прикладные модули посредники, созданные для перехвата сеансов связи по определенным протоколам, разрешают проводить только необходимые, безопасные и допустимые операции. На это приверженцы Stateful Inspection заявляют, что она может обеспечить такой же уровень безопасности при передаче графика, но при этом нет необходимости жертвовать производительностью из за дублирования firewall системой каж дого сетевого приложения. Продукт Raptor компании AXENT, имеющий наиболее внушительный набор моду лей посредников, также предоставляет ряд возможностей для управления системой защиты, отсутствующих в FireWall 1 — самом лучшем продукте среди поддерживающих технологию Stateful Inspection, но “распла чивающимся” за это снижением общей производительности.

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

При отладке соединения по обе стороны межсетевого экрана proxy типа с помощью различных анализаторов протоколов, обычно более трудно выполнение трассировки данных, чем в случае при использовании техноло гии Stateful Inspection. Причина этого явления состоит в том, что порты источники и порядковые номера паке тов, используемые для их идентификации, изменяются при перезаписи заголовка пакета, сильно затрудняя его визуальное определение. Необходимо более тщательно исследовать уровень представления данных (модели OSI), чтобы найти зацепки, которые могли бы помочь идентифицировать пакеты. При этом очевидно, что отсле живание статуса пакетов в разных точках сети сверхтрудная задача даже без ее дополнительного усложнения. Следует также помнить, что при диагностировании проблем в случае использования трансляции сетевых адре сов (Network Address Translation — NAT) могут возникнуть такие же сложности, поскольку заголовки пакетов при этом тоже изменяются.

Кроме продукта FireWall 1 компании Check Point, метод Stateful Inspection используется в рассмотренных ниже firewall системах компаний Cisco, NetGuard и NetScreen. В целом производительность этих систем выше произ водительности продуктов компаний AXENT, CyberGuard и Secure Computing, в которых применена proxy техно логия. В действительности продукт PIX компании Cisco работает со скоростью, близкой к полной скорости ка нала.

2. Примеры специфических политик для отдельных сервисов

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

Ниже приведены таблицы учета административных проблем, связанных с доступом к Интернету при приме нении брандмауэра (таблица 1) и сводная таблица по политике безопасности для брандмауэра (таблица 2). Организация может захотеть поддерживать некоторые сервисы без усиленной аутентификации. Например,

48.3

Конфигурирование Firewall

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

Таблица 1.

Учет административных проблем

3. Решения ООО “Конфидент” для типового проекта системы безопасности сети

Firewall — 1 фирмы Checkpoint

FireWall 1 — это программный продукт компании Check Point Software Technologies (распространяемый так же некоторыми другими компаниями, например, SunSoft). В основе FireWall 1 лежит технология многоуров невой фильтрации с формированием и анализом состояния сетевых соединений, обеспечивающая надеж ную защиту в сочетании с высокой эффективностью и полной прозрачностью для легальных пользовате лей. Эта технология дополнена средствами централизованного администрирования (конфигурирования, анализа и аудита) защитных механизмов, а также логически замкнутым набором криптографических средств.

FireWall 1 состоит из двух основных компонентов:

•управляющий модуль;

•экранирующий модуль.

Далее мы рассмотрим (применительно к версии 2.1 программного продукта) функции каждого из модулей.

Управляющий модуль FireWall-1

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

48.4

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

48.5

Конфигурирование Firewall

Конфигурирование FireWall 1 начинается с описания объектов, которые межсетевой экран должен защи щать. В число объектов входят хосты (компьютеры с одним сетевым интерфейсом), шлюзы (компьютеры с несколькими сетевыми интерфейсами), маршрутизаторы, сети, области управления. Каждый объект имеет набор атрибутов, таких, как сетевой адрес, маска подсети и т.п. Часть этих атрибутов следует задать вруч ную, остальные автоматически извлекаются из информационных баз — NIS/NIS+, SNMP MIB, DNS.

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

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

Используемый сетевой сервис является компонентом правил фильтрации наряду с исходным и целевым адре сом. Прежде чем использовать сервис при задании правил, необходимо определить его свойства. FireWall 1 со держит предварительно подготовленные определения всех стандартных TCP/IP сервисов, разбитых на четыре категории — TCP, UDP, RPC, ICMP. Пятая категория, “Others”, оставлена для нестандартных сервисов. В подавля ющем большинстве случаев она остается пустой.

Традиционно трудны для фильтрации UDP сервисы, поскольку отсутствует фаза установления виртуального соединения, равно как и контекст диалога между клиентом и сервером. FireWall 1 сам вычисляет этот кон текст, отслеживая все UDP пакеты, пересекающие межсетевой экран в обоих направлениях, и ассоциируя запросы с ответами на них. В результате получается аналог виртуального соединения для датаграммного про токола, а все попытки нелегального установления подобного соединения, равно как и датаграммы, следую щие вне установленных соединений, обрабатываются в соответствии с выбранной политикой безопасности. RPC сервисы сложны для фильтрации из за переменных номеров используемых портов. FireWall 1 отслежи вает RPC трафик, выявляя запросы к функции portmapper и извлекая из ответов выделенные номера портов. После того, как дано описание сетевых объектов, пользователей и сервисов, на управляющей станции FireWall 1 строится единая база правил, отражающих сетевые аспекты политики безопасности организации. Обычно эта база строится средствами графического интерфейса, однако возможно и непосредственное программирова ние на языке описания правил фильтрации Inspect.

Каждое правило состоит из следующих полей:

•исходный адрес;

•целевой адрес;

•используемые сервисы;

•действие, совершаемое над сетевым пакетом (пропустить, отвергнуть, аутентифицировать, шифровать);

•режим протоколирования;

•объекты, применяющие данное правило.

Рассмотрим пример. Пусть имеется конфигурация, приведенная на рис. 1. Локальная сеть (localnet) должна предоставлять вовне только почтовый сервис. В то же время, пользователи локальной сети могут пользоваться всеми сетевыми сервисами, внутренними и внешними. В экранирующей подсети (dmz) располагаются обще доступные серверы http и ftp; сами эти серверы не должны выступать в роли инициаторов сетевых контак тов. Авторизованным пользователям, располагающимся во внешней сети, разрешен удаленный доступ в ло кальную сеть. Наконец, следует позаботиться о том, чтобы экранирующий шлюз был прозрачен для сетевого трафика, то есть чтобы он не мог выступать в роли отправителя или получателя сетевых пакетов. Результиру ющий набор правил изображен на рис. 2.

FTP.HTTP.ETC.

DMZ

Рис. 1. Конфигурация с локальной сетью и экранирующей подсетью.

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

Наконец, база правил преобразуется в текст на языке Inspect, а затем выполняется компиляция, результат ко торой передается на все объекты, вовлеченные в процесс фильтрации.

48.6

Конфигурирование Firewall

Рис. 2. Набор правил для защиты конфигурации

Экранирующий модуль FireWall-1

Экранирующий модуль FireWall 1 устанавливается на всех компонентах корпоративной сети, производящих фильтрацию сетевых потоков данных. Это могут быть серверы с одним сетевым интерфейсом (тогда модуль за щищает только данный сервер) или шлюзы с несколькими интерфейсами (тогда модуль экранирует подсеть).

Экранирующий модуль решает три основные задачи:

•фильтрация сетевого трафика;

•протоколирование информации и возбуждение сигналов тревоги;

•шифрование/дешифрование информации.

Экранирующий модуль встраивается в ядро операционной системы между канальным и сетевым уровнями. Он перехватывает все пакеты, поступающие из/в сетевой карты и обрабатывает их в соответствии со специ фицированной базой правил. Такая обработка производится для каждого сетевого интерфейса на серверах и шлюзах. При фильтрации по очереди просматриваются все правила, заданные для данного интерфейса. Если подходящее правило найдено, выполняются заданные в нем действия (протоколирование, шифрование и т.д.), после чего пакет пропускается или отвергается. Таким образом, экранирующий модуль FireWall 1 работает до и независимо от сетевых механизмов операционной системы. Работа в пространстве ядра позволяет из бежать многочисленных переключений контекстов процессов, что существенно повышает эффективность фильтрации.

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

Рассмотрим вопросы конфигурирования более подробно.

Краткое описание

Технология Stateful Inspection FireWall 1

В FireWall 1 реализована архитектура Stateful Inspection технология проверки с учетом состояния протокола, ко торая реализует все необходимые возможности firewall на сетевом уровне.

Сущность этой технологии заключается в следующем: модуль инспекции анализирует данные, полученные от всех уровней коммуникаций. Эти данные о “состоянии” и “контексте” запоминаются и обновляются ди намически, обеспечивая виртуальную информацию о сессии для отслеживания протоколов без установки соединений (таких, как RPC и приложений основанных на UDP). Данные, полученные из состояний соеди нений и приложений, конфигурации сети и правил безопасности, используются для генерации соответству ющего действия и либо принятия, либо отвержения, либо шифрации канала связи. Любой трафик, кото рый явным образом не разрешен правилами безопасности, блокируется по умолчанию и одновременно в реальном времени генерируются сигналы оповещения, предоставляя системному администратору полную информацию о состоянии сети.

48.7

Конфигурирование Firewall

Политика безопасности

Политика безопасности FireWall 1 формируется в виде правил и свойств.

База правил это упорядоченный набор правил, с помощью которых проверяется каждое соединение. Если ис точник соединения, назначение и тип сервиса соответствуют правилу, то будет выполнено действие, описан ное в правиле (Accept, Encrypt, Reject, Drop). Если соединение не соответствует ни одному из правил, оно бло кируется, в соответствии с принципом “Что специально не разрешено, всегда запрещено”.

Таблица 4.

Сравнение технологий

Модуль проверки FireWall—1

Модуль проверки FireWall 1 динамически загружается в ядро операционной системы, между уровнем Data Link и Network (уровни 2 и 3). Когда приходит первый пакет нового соединения, модуль проверки FireWall— 1 проверяет базу правил для определения, должно ли быть разрешено это соединение. После того, как со единение установлено, FireWall 1 добавляет его во внутреннюю таблицу соединений. По соображениям про изводительности, последующие пакеты соединения проверяются по таблице соединений, а не по базе пра вил. Пакету разрешается быть переданным только, если соединение имеется в таблице соединений?

В таком соединении, как здесь, соединение полностью ведется модулем проверки FireWall 1 (рис. 3).

Application

Security Server

Prezentation

Session

Transport

Network

Inspection module Data Link

Physica

Рис. 3. Соединение управляется модулем проверки FireWall—1

Аутентификация на security сервере и безопасность содержания

FireWall—1 позволяет администратору определять политику безопасности для каждого пользователя, где не толь ко источник соединения, назначения и сервис проверяются, но и каждый пользователь должен быть аутенти фицирован. Более того, соединения могут быть разрешены или запрещены, исходя из их содержания. К приме ру, почта для или от определенных адресов может быть запрещена или перенаправлена, доступ может быть зап рещен к заданным URL’s, и включена анти вирусная проверка над передаваемыми файлами.

Аутентификация и проверка содержимого обеспечиваются набором серверов безопасности FireWall—1, ра ботающих на уровне приложения.

Когда работает сервер безопасности FireWall 1, модуль проверки перенаправляет все пакеты соединения к серверу безопасности, который выполняет требуемую аутентификацию и/или проверку содержимого. Существуют пять серверов безопасности FireWall—1, как показано в таблице 5.

48.8

Конфигурирование Firewall

Таблица 5.

Серверы безопасности FireWall 1 свойства

Распределение нагрузки

FireWall 1 позволяет распределить вычислительную нагрузку на любое число серверов, в режиме, прозрач ном для клиента.

При обработке запроса FireWall 1 направляет его на один из серверов исходя из алгоритма балансирования загрузки, заданного системным администратором.

Алгоритм распределения нагрузки

1.По загрузке сервера. FireWall—1 запрашивает серверы с целью определения того из них, который лучше способен обслужить новое соединение.

2.По времени ответа на ping (round trip). FireWall 1 использует ping для определения времени прохожде ния пакета между FireWall 1 и каждым из серверов и выбирает сервер с наименьшим временем ответа.

З. По кругу. FireWall 1 назначает следующий сервер в списке.

4.Случайный. FireWall—1 назначает сервер в случайном порядке.

5.По доменному имени. FireWall 1 назначает “ближайший” сервер, основываясь на доменных именах.

Аутентификация

FireWall 1 обеспечивает 3 вида аутентификации:

1.Аутентификация пользователя, которая позволяет администратору давать каждому пользователю свои привилегии доступа. Аутентификация пользователя включает сервер безопасности HTTP FireWall—1, кото рый предоставляет механизм для аутентификации пользователей сервиса HTTP, как входящего, так и исходя щего.

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

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

FireWall 1 поддерживает следующие схемы аутентификации для каждого пользователя:

1.S/Кеу Пользователю требуется ввести значения S/Key для данной итерации.

2.SecurlD — Пользователю требуется ввести номер, показанный на SecurID карте Security Dynamics. З . По паролю — от пользователя требуют ввести его (или ее) пароль OS.

4.Внутренняя — пользователь должен ввести его (или ее) внутренний пароль FireWall—1 на мосте.

5.RADIUS — пользователь должен ввести ответ на запрос сервера RADIUS.

6.AssifreNet Pathways — пользователь должен ввести ответ на запрос сервера AssureNetPathway.

Таблица 6.

Сравнение типов аутентификации

Проверка потока данных

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

48.9

Конфигурирование Firewall

FireWall—1 обеспечивает проверку содержания для HTTP, SMTP и FTP с использованием серверов безопас ности FireWall 1. Для каждого соединения, установленного через сервер безопасности FireWall 1, админист ратор может управлять доступом в соответствии с различными параметрами протокола данного сервиса: URL, именами файлов, командами FTP PUT/GET, типами запросов и так далее.

Наиболее важное применение проверки содержания — антивирусная проверка передаваемых файлов. Ан тивирусная поддержка полностью интегрирована с FireWall 1.

Проверка содержания реализуется через тип объекта FireWall 1 Resource. Определение объекта Resource за дает ряд составляющих, которые могут быть доступны через определенный протокол. Вы можете задавать FireWall 1 Resource на основе протоколов HTTP, FTP и SMTP.

Например, вы можете задать URI ресурс, чьими атрибутами будет список URL и схем HTTP и FTP. Ресурс может быть использован в базе правил точно таким же образом, как и любой другой тип сервиса, и для него также могут быть определены стандартные процедуры записи события в журнал и оповещения администратора си стемы для обеспечения возможности наблюдения за использованием данного ресурса.

HTTP

Ресурсы URI могут определять схемы (HTTP, FTP, GOPHER и т.д.), методы (GET,PUT, и т.д.), машины (например, ”.corn”), пути и запросы. Также может быть задан файл, содержащий список IP адресов и серверов.

SMTP

Протокол SMTP, разработанный для обеспечения наиболее удобного общения между людьми через Internet, и расширенный для поддержки не только e mail, но и передачи файлов, предоставляет выбор системному ад министратору, который хочет одновременно поддерживая прозрачность соединений, не позволять наруши телям проникнуть внутрь сети.

FireWall—1 предлагает сервер SMTP, который обеспечивает максимально детальный контроль над соедине ниями SMTP. Определяя SMTP ресурсы, администратор безопасности имеет возможности:

•спрятать в исходящей почте адрес From под стандартным общим адресом, закрыв тем самым внутреннюю архитектуру сети и реальные имена пользователей.

•перенаправить почту, посланную на данный адрес То (например для root) на другой почтовый адрес.

•уничтожать всю почту от заданного адреса.

•обрезать все прикрепленные к письмам файлы.

•убирать поля Received из исходящей почты для закрытия внутренней структуры сети.

•уничтожать все письма размера более заданного.

FTP

Сервер безопасности FTP обеспечивает аутентификацию и проверку содержимого, основываясь на командах FTP (PUT/GET), ограничениях на имена файлов и антивирусной проверке файлов.

Антивирус

Антивирусная проверка является составной частью такого свойства FireWall 1, как проверка содержимого потоков данных и значительно снижает уязвимость защищенных машин.

Проверка всех передаваемых файлов проводится с использованием встроенного антивирусного модуля. Конфигурация этого механизма (какие файлы проверять, что делать с зараженными файлами) полнос тью интегрирована в политику безопасности (базу правил). Все инструменты управления и проверки FireWall—1 доступны для журналирования и оповещения о случаях нахождения зараженных файлов.

Конфигурирование FireWall—1 Простая Конфигурация

В примере, изображеном на рис. 4. Checkpoint FireWall 1 будет установлен на шлюзе, именуемом в приведен ных ниже правилах как monk.

Gateway

48.10

Конфигурирование Firewall

Типичная политика безопасности

Для показанной выше конфигурации может быть принята следующая стратегия защиты:

•внешние сети могут только посылать почту локальным компьютерам.

•внутренние компьютеры могут обращаться ко всей сети: локальной и Internet.

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

Реализация политики безопасности

Чтобы реализовать политику безопасности, необходимо выполнить следующие действия:

1. Определить сетевые объекты, используемые в правилах.

Для описанной конфигурации необходимо определить gateway (монах), почтовый сервер (mailsrvr) и локаль ную сеть (localnet).

2.Определить услуги, используемые в данной конфигурации (необязательно).

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

В большинстве случаев необходимо только определить имя, так как CheckpointFireWall 1 может получить па раметры объекта из соответствующего файла, базы NIS+ или базы данных DNS.

3.Создать базу правил — правила для принятия решения о пропуске или уничтожении пакетов и их регист рации в журнале.

4.Установить базу правил (инспекционный код на шлюзе (шлюзах)).

Следующий шаг в реализации стратегии защиты — создать базу правил с использованием редактора. В ре дакторе базы правил правила выражены в терминах следующих элементов:

Первые четыре элемента описывают попытку соединения:

Источник откуда соединение исходит Назначение — куда соединение направлено Сервис — тип приложения

Время время суток начала соединения (новое в версии 3.0) Следующие два элемента указывают на то, что должно быть выполнено:

Действие — что должно быть сделано с данным соединением Регистрация — регистрировать пакет или вы дать сигнал тревоги

Последний элемент указывает, на какой модуль FireWall будет установлено правило, определенное первыми пятью элементами:

Установить на — FireWall Module, который будет обеспечивать выполнение правила

В этом примере имеются только два правила в соответствии со стратегией, изложенной выше.

Первое правило (внешние сети могут посылать только почту на почтовый сервер) может быть выражено в редакторе правил так, как это отображено в табл. 7.

Таблица 7.

Второе правило (локальные компьютеры могут обращаться ко всей сети: localnet и Internet) отражается в редакторе правил так, как это отображено в табл. 8.

Таблица 8.

Обязательное запрещение

В FireWall 1 реализован принцип “Что явно не разрешено, то Запрещено” FireWall 1 неявно добавляет еще одно правило в конец базы правил, запрещающее все попытки связи, не описанные другими правилами. Так как правила применяются последовательно к каждому пакету, только пакеты, не описанные первыми двумя правилами, инспектируются последней строкой. Однако, если полагаться на это неявное правило, запрещаю щее все пакеты, то они не будут регистрироваться потому, что регистрироваться могут только пакеты, опреде ленные явным правилом. Чтобы регистрировать эти пакеты, необходимо явно определить правило типа “ни один из вышеупомянутых” так, как это отображено в табл. 9.

Таблица 9.

Если явно не определять такое правило, Checkpoint FireWall—1 неявно определит его сам, и пакеты будут унич тожены. Checkpoint FireWall 1 ни в коем случае не допустит прохождения нераспознанных пакетов. Преиму ществами явного определения подобного правила является то, что:

•Вы можете задать регистрацию уничтоженных пакетов.

•Вы можете подстроить стратегию защиты.

•Поведение системы становится более прогнозируемым и понятным.

48.11

Конфигурирование Firewall

“Сокрытие” Gateway

Правила, описанные выше, имеют недостаток — они предоставляют компьютерам локальной сети доступ к ресурсам Gateway (подразумевается, что они зарегистрированы на Unix системе). Обычно такая ситуация не желательна. Чтобы предотвратить доступ с любого компьютера (не только с локального) к Gateway, необходи мо добавить правило (предшествующее остальным) так, как это отображено в табл. 10.

Таблица 10.

Защита Gateway подобным способом делает его недоступным другим пользователям и приложениям (кроме консоли управления Checkpoint FireWall 1). Gateway становится невидимым сетевым объектом как для кли ентов сети, так и за ее пределами.

Чтобы сильнее защитить Gateway, можно добавить следующее правило, которое будет изымать любой пакет, порождаемый на Gateway (см. табл.11).

Таблица 11

Поле Install On в этом правиле определено как Source потому, что по умолчанию Gateway устанавливает пра вила только на входящий трафик. Правило определено для компьютера с именем monk, но так как monk оп ределен как Source, правило действует только на выходящий трафик (правило применяется только к паке там, порождаемым и отправляемым с компьютера monk). Если бы поле Install On было бы определено как Gateway, правило применялось бы только к пакетам, приходящим на monk и одновременно порожденным на нем. Другими словами, ни к каким пакетам вообще.

Пример более сложной конфигурации

Рассмотрим следующую конфигурацию (см. рис. 5).

Localnet

Рис. 5 Пример конфигурации сети

Эта конфигурация подобна первой, за исключением того, что добавлен общий сервер (DMZ — демилитаризо ванная зона). DMZ обеспечивает HTTP, FTP и другие услуги для глобальной сети, но не является инициатором никакого графика. DMZ фактически третий интерфейс, присоединенный к Gateway, и может быть сетью, под сетью или отдельной машиной.

Стратегия защиты для этой конфигурации аналогична стратегии защиты, рассмотренной в предыдущем приме ре, но содержит дополнительное правило. Это правило обеспечивает доступ по FTP и HTTP к DMZ из Internet (см. табл.12).

Таблица 12

Если указано Gateway, то правило действует на компьютерах, определенных как шлюз (в окне Host Properties). Правило применимо ко всем пакетам, идущим в направлении, определенном в свойствах “Apply Gateway Rules to Interface Direction” в окне Control Properties/Security Policy.

48.12

Конфигурирование Firewall

Если указано Routers, то правило устанавливается на соответствующих интерфейсах на всех маршрутизато рах, используя возможность автообзора FireWall 1. Checkpoint FireWall 1 генерирует Списки Доступа для мар шрутизаторов. Нужно отметить, что только со списками доступа можно реализовать лишь неполное подмно жество функциональности модуля FireWall 1. Например, невозможно создавать защищенные соединения FTP как описано в “Исходящие соединения FTP”.

Если объект указан по имени, правило проверяется как для входящих, так и для выходящих пакетов.

Аутентификация

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

Эти свойства включают разрешенные источники, назначения и времена суток.

Таблица 13

Install On

Anti-Spoofing

Spoofing методика, где “злоумышленник” пытается получить несанкционированный доступ, изменяя содер жимое IP пакета нестандартными средствами. В результате такой пакет появляется, как если бы он был ини циирован в сети с более высокими привилегиями доступа. Например, пакет из Internet может быть замаски рован под пакет из локальной сети. Если такой пакет не обнаружить, то он сможет получить неограниченный доступ к локальной сети.

FireWall—1 содержит средства для локализации подобных действий. Эти средства требуют, чтобы пакет, при ходящий на соответствующий интерфейс, удовлетворял некоторым требованиям, в частности, имел тот же адрес источника, что и адрес интерфейса. Например, при возникновении подобной ситуации FireWall 1 иден тифицирует пакет, приходящий из Internet и содержащий локальный IP адрес, изымает его и выдает тревогу. Этот тип “antispoofing” защиты может быть достигнут только при использовании интегрированной системы типа FireWall 1, так как данная система имеет доступ как к интерфейсу, через который пакет прибыл, так и к содержимому уровня IP пакета, а также знает все о топологии внутренней сети и умеет регистрировать по добные события и выдавать предупреждения.

Свойство “Antispoofing” определяется в окне свойств сетевого объекта, который будет реализовывать данное правило. Например, если Gateway должен обеспечить “antispoofing”, то необходимые параметры определяют ся в окне свойств Gateway компьютера (рис. 14). Аналогично, параметры spoof—трэкинга маршрутизатора оп ределены в окне свойств интерфейса маршрутизатора.

Журналирование событий и сигналы тревоги

FireWall—1 позволяет записывать полную информацию о происходящих событиях (пропущенных и задержан ных пакетах) в файл регистрации. Средство просмотра файла регистрации FireWall 1 предоставляет возмож ность просматривать файл регистрации с помощью различных фильтров и контекстного поиска для быстрого и эффективного извлечения необходимой информации. Вы можете задать оповещение администратора когда FireWall— 1 уничтожает или пропускает заданный пакет.

Сообщение может передаваться разными способами. В виде сообщения на центральную консоль, в виде по чтового сообщения на один из предопределенных адресов или в виде Trap (сообщения о событиях) протоко ла SNMP фактически, можно определить любую команду OS, которая будет выполнена в случае возникнове ния нештатной ситуации. Все предупреждения также регистрируются в журнале.

Дополнительно Вы можете выбрать режим просмотра записей журнала регистрации работы или активных со единений, сделав соответствующий выбор в “Drop down” списке в панели инструментов средства просмотра log файла.

48.13

Конфигурирование Firewall

Установка базы правил

При инсталляции базы правил, чтобы привести ее в действие, FireWall 1 проверяет ее на логичность и непро тиворечивость, затем генерирует и загружает Инспекционный Код в каждый из заданных модулей FireWall. Если сетевой объект маршрутизатор, FireWall—1 генерирует и устанавливает на него соответствующий Спи сок Доступа, а не Инспекционный Код.

Свойства

Стратегия защиты определена не только Базой Правил, но и параметрами в окне Control Properties/Security Policy.

Эти параметры дают возможность пользователю управлять общими аспектами проверки пакетов и в то же са мое время освобождают пользователя от необходимости определять рутинные подробности в редакторе базы правил.

Принцип работы Архитектура FireWall-1

Checkpoint FireWall—1 состоит из двух основных модулей:

Модуль Управления

Модуль Управления включает графический интерфейс пользователя и собственно компоненты управления. Графи ческий интерфейс пользователя позволяет работать с базами данных Checkpoint FireWall 1: Базой Правил, сетевыми объектами, услугами, пользователями и т.д.

Модуль FireWall

Модуль FireWall включает Инспекционный Модуль, два “демона” (snmpd и fwd) и сервера безопасности. Модуль FireWall непосредственно осуществляет стратегию защиты, ведение журнала событий, и общает ся с Компонентой Управления посредством “демонов”.

Стратегия защиты Checkpoint FireWall 1 определена в терминах сетевых объектов, услуг, пользователей и пра вил, задающих взаимодействие этих объектов. Как только они определены Модулем Управления, генерирует ся Инспекционный Код и затем устанавливается на FireWall, реализующий стратегию защиты рис.6.

* Данный канал является защищенным, если установлена криптографическая защита (VPN модуль Firewall)

Рис. 6. Компоненты FireWall 1

Модель клиент/сервер

Управляющий модуль может быть установлен в конфигурации клиент сервер. Графический интерфейс на кли енте может работать под управлением Windows 95, Windows NT или X/Motif GUI и управлять сервером на одной из поддерживаемых платформ (Windows NT, SunOS 4.1.3, Solaris 2.x, HP UX 9 и 10).

Клиентская часть взаимодействует с пользователем посредством графического интерфейса. Все данные (базы правил, файлы конфигураций) хранятся и обрабатываются на сервере, который занимает промежуточное по ложение между клиентской частью и Модулем Управления. Например, пользователь запрашивает установку Security Policy, в результате сервер обращается к Модулю Управления, который транслирует запрос далее и сообщает результаты серверу. Сервер, в свою очередь, передает их клиенту.

Как и в предыдущих версиях пакета FireWall 1, также доступен графический интерфейс пользователя на основе OpenLook. OpenLook GUI содержит обе компоненты (клиент и сервер) и может использоваться на любой из плат форм, поддерживающих OpenLook (SunOS 4.1.3 и выше, Solaris 2 х, HP UX 9 and 10).

48.14

Конфигурирование Firewall

В конфигурации, представленной на рисунке 7, функциональность Модуля Управления разделена на две ра бочие станции (simon and floyd). Модуль Управления, включая базу данных FireWall 1, расположенный на ком пьютере simon, является сервером. Клиентская часть (GUI) расположена на компьютере floyd.

Пользователь, управляющий политикой безопасности, работает за компьютером floyd, а все базы правил рас положены на компьютере simon. Модуль FireWall, установленный на компьютере monk, защищает внутреннюю сеть, реализуя политику безопасности.

Internet

Router

Management FireWalled

Server (monk)

GUI

Client (floyd)

Рис. 7. Конфигурация клиент/сервер

Сетевое соединение между клиентом и сервером защищено, что позволяет реализовать удаленное управление. Например, компьютер floyd может располагаться вне локальной сети. Таким образом, различные организации или отделения могут управляться из одного, общего центра управления Управляющим Модулем.

GUI клиент Модуля Управления, Сервер Модуля Управления и модуль FireWall могут устанавливаться на раз личных компьютерах или на одном и том же компьютере, если все три программы могут работать на этой плат форме. Тогда администратор сети определяет политику безопасности, используя Модуль Управления на Цен тре Управления, который, кроме того, является защищенным Gateway (установлена компонента FireWall Module), реализующим политику безопасности.

На рис. 8 показана распределенная конфигурация, где Модуль Управления (в клиент серверной реализации) контролирует три модуля FireWall, где каждый из них установлен на разных платформах и защищает три гетеро генные сети.

This Control

Module...

Management

Server

Рис. 8. Распределенная конфигурация FireWall—1

48.15

Конфигурирование Firewall

Модуль управления. База Правил

После того, как сетевой администратор определил стратегию защиты — Базу Правил и параметры объектов (сети, услуги, адреса компьютеров и пользователей), используемых в правилах, стратегия преобразуется в Ин спекционный Сценарий. Инспекционный Код, генерируемый из Инспекционного Сценария, передается затем по защищенному каналу от Станции Управления Checkpoint FireWall 1, поддерживающей базу данных, на ком пьютер с демонами Checkpoint FireWall 1. То есть, на модули FireWall, которые обеспечивают стратегию защи ты сети. Демон Checkpoint FireWall 1 загрузит новый Инспекционный Код в Модуль Проверки Checkpoint FireWall 1. Сетевой объект, на котором Модуль Проверки Checkpoint FireWall 1 установлен, называется “FireWalled system”, защищенный Gateway.

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

Связь между Инспекционными Модулями и Станцией Управления осуществляется в защищенном режиме. Ин спекционные Модули общаются со Станцией Управления, используя SNMP агента.

Процедура развертывания Checkpoint FireWall—1 полностью централизована. Другими словами, несмотря на то, что стратегия защиты может быть создана для более чем одного сетевого объекта и, как показано в следу ющем разделе, выполняться на нескольких уровнях, все объекты все равно будут работать в контексте еди ной стратегии защиты, одной Базы Правил и на основе единого централизованного файла регистрации.

Модуль для управления маршрутизаторами

В случае маршрутизаторов, Списки Доступа, сгенерированные на основе стратегии защиты, устанавливаются Checkpoint FireWall—1 непосредственно на маршрутизаторах. Для Cisco FireWall—1 загружает список досту па, используя Expect сеанс, который эмулирует сеанс TELNET на маршрутизатор. Для маршрутизаторов Wellfleet, Checkpoint FireWall 1 использует SNMP.

Менеджер сетевых объектов

Менеджер Сетевых Объектов определяет элементы, которые являются частью стратегии защиты. Только те объекты, которые являются частью стратегии защиты, должны быть определены пользователем. Они могут включать:

•сети и подсети

•серверы и рабочие станции (защищенные или нет)

•маршрутизаторы

•домены Internet

•логические серверы (среди которых можно произвести автоматическое распределение вычислительной нагрузки)

•группы

Каждый объект имеет набор атрибутов: сетевой адрес, маску подсети, и т.д. Некоторые из этих атрибутов оп ределяются пользователем, в то время как другие извлекаются Checkpoint FireWall 1 из сетевых баз данных (файлов) из /etc, Сетевых Информационных служб (NIS+ и др), сетевых баз данных DNS. Агенты SNMP исполь зуются для извлечения дополнительной информации, включая конфигурацию интерфейсов компьютеров, маршрутизаторов и шлюзов. Объекты могут быть объединены в группы и иерархии.

Диспетчер пользователей

Checkpoint FireWall 1 предоставляет возможность установить привилегии доступа непосредственно для каждого пользователя и для группы. Можно создавать группы пользователей и задавать привилегии доступа для них, включая разрешенных адресатов и получателей пакетов, а также схемы идентификации пользователей (“Аутентификация”),

Диспетчер сетевых служб

Диспетчер Сетевых Служб определяет типы сервисов, известных системе и используемых в стратегии защи ты. Все сетевые услуги экранируются и контролируются, даже те, которые не определены явно. Широкий на бор ТСРДР и Internet услуг определен заранее и содержит слежующее:

•Стандартные услуги ARPA NET: TELNET, FTP, SMTP и т.д.

•Berkeley г услуги: riogin, rsh и т.д.

•SunRPC услуги: NIS + /yellow pages, NFS и т.д.

•Расширенные протоколы Internet типа HTTP, Gopher, Archie и многие другие.

•IP услуги Internet Control Message Protocol (ICMP), Routing Internet Protocol (RIP), SNMP и т.д.

Новые услуги могут быть определены путем выбора типа сервиса и установки его атрибутов. Типы сервисов включают:

•Transmission Control Protocol (TCP)

•User Datagram Protocol (UDP)

•Remote Procedure Call (RFC)

•Internet Control Message Protocol (ICMP)

48.16

Конфигурирование Firewall

•Другие (предоставляется возможность формирования описания сервиса и протокола, в случае несоответ ствия набору стандартных атрибутов). Сервис определяется, используя простые выражения и макросы.

Услуги могут быть сгруппированы в семейства и иерархии. Например: NFS (программа монтирования, NFS сервер, диспетчер блокировок), NIS+ /ур, и WWW (HTTP, FTP, Archie, Gopher, и т.д.).

Монитор состояния системы

Модуль Проверки FireWall 1 включает в себя мощные средства отображения состояния, проверки и оповеще ния о неполадках в системе. Окно Состояния Системы отображает текущее состояние всех Модулей FireWall и маршрутизаторов Wellfleet в любое время. Генерируемые отчеты включают состояние Модуля FireWall, стати стику по пакетам (пропущено, блокировано, зарегистрировано, и т.д.).

В Unix системах Checkpoint FireWall 1 устанавливает собственный демон SNMP на компьютеры с системой FireWall. SNMP Checkpoint FireWall 1 демон использует или стандартный MIB SNMP, или расширенный MIB Checkpoint FireWall 1. В системе Windows NT FireWall— 1 расширяет встроенный SNMP демон добавлением расширений аген та, поддерживающих FireWall 1 MIB. Агент SNMP, используемый Модулями FireWall, может экспортировать ин формацию в другие интегрированные с Checkpoint платформы управления сетями. Кроме того, Checkpoint FireWall 1 может использовать TRAP по SNMP, как один из вариантов оповещения администратора.

Средство просмотра статистики

В Базе Правил администратор может определять правила регистрации и оповещения администратора для лю бой попытки соединения, независимо от того, разрешено данное соединение или нет. Форматы данных для регистрации и предупреждения, а также действия, связанные с ними, открыты и могут быть настроены пользо вателем. Стандартные форматы содержат информацию об источнике и адресате, сервисе, используемом про токоле, времени и дате, исходном порте, предпринимаемом действии (установлено соединение, пропущено, блокировано, состоялся обмен ключами шифрования, трансляция адресов), файле регистрации и типе пре дупреждения, номере правила, пользователе, а также Модуле FireWall, который инициировал зарегистриро ванное событие. Любая информация о попытке связи может регистрироваться или использоваться для вызо ва сообщения (например, высветить окно с предупреждением, послать почтовое сообщение, запустить лю бой заданный пользователем механизм — программу или отослать Trap).

Программа просмотра статистики отображает каждое регистрируемое событие, включая попытки связи, эта пы инсталляции стратегии защиты, выключение системы и т.д. Для каждого события будет отображаться со ответствующая информация. Информационные поля могут отображаться или скрываться. Цвета и иконки, связанные с событиями и полями, обеспечивают легко читаемое визуальное представление.

Журналы регистрации и регистрационные записи можно фильтровать и осуществлять поиск по ним, их мож но распечатать или сгенерировать отчет. Поиск быстро отслеживает события, представляющие интерес для администратора. Отчеты генерируются с применением критериев отбора к выделенным полям, обеспечивая сложные и исчерпывающие выборки. Отчеты могут просматриваться, экспортироваться в текстовый формат или выводиться на PostScript — устройство печати.

Интерактивные возможности просмотра показывают действия системы, текущие соединения и сигналы тре воги в реальном масштабе времени.

Интерфейс пользователя

Checkpoint FireWall 1 включает мощный и интуитивный графический интерфейс пользователя так же, как и интерфейс командной строки. Консоль Управления Checkpoint FireWall 1 работает в системе Windows, Solaris, OpenWindows, OPEN LOOK X11R5, X/Motif. Все возможности Checkpoint FireWall 1 доступны из командной строки, что позволяет работать с ним со стандартного терминала.

Интерфейс командной строки также может использоваться вместе с инструментальными средствами стандар тной системы типа awk и grep, вызывая созданные пользователем процедуры для анализа и сканирования файла регистрации и состояния. Кроме того, различные Базы Правил могут активизироваться в разное вре мя дня и/или недели, используя интерфейс командной строки вместе с утилитой crontab.

ßçûê INSPECT Checkpoint FireWall- 1

В Checkpoint FireWall 1 стратегия защиты описана Инспекционным Сценарием на языке INSPECT FireWall 1. Инспекционные Сценарии представляют собой легко читаемые ASCII файлы и могут быть написаны с исполь зованием любого текстового редактора. Графический интерфейс пользователя генерирует Инспекционные Сценарии на том же самом языке. Впоследствии Инспекционные Сценарии компилируются в Инспекционный Код, который загружается и выполняется Модулями FireWall.

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

Инспекционный модуль Firewall

Модуль FireWall включает два “демона” Checkpoint FireWall 1 (snmpd и fwd) и Инспекционный Модуль. Checkpoint FireWall 1 обычно устанавливается на dual homed компьютере (Gateway), но может также быть ус тановлен и на информационном сервере. Так как Checkpoint FireWall 1 загружается в ядро операционной системы, нет необходимости запрещать трансляцию IP пакетов, потому что Checkpoint FireWall 1 обрабаты вает пакеты до их пересылки. Кроме того, процессы и демоны на шлюзе не должны уничтожаться или моди фицироваться, так как Checkpoint FireWall 1 работает с ними на самом нижнем сетевом уровне.

48.17

Конфигурирование Firewall

Поддержка Windows NT

FireWall модуль может устанавливаться на NT системы. Вся функциональность FireWall—1 для Unix—систем доступна и для Windows NT, в том числе и модель Клиент/Сервер.

Поддержка маршрутизаторов Bay Networks и Xylan

Механизм проверки с учетом состояния протокола FireWall—1 теперь может быть реализован на маршрути заторах Bay Networks и коммутаторах Xylan. При этом поддерживаются все стандартные свойства FireWall 1, за исключением шифрования, аутентификации и адресной трансляции.

Это решение позволяет существенно усилить уровень безопасности при реализации на уровне маршрутиза торов и коммутаторов.

Архитектура инспекционного модуля

Когда Инспекционный Модуль установлен на шлюзе, он управляет графиком, проходящим между сетями. Ин спекционный Модуль динамически загружается в ядро операционной системы, между уровнем Data Link и сетевым (уровни 2 и 3). Так как Data Link на самом деле является сетевой картой (NIC), а сетевой уровень — первым уровнем стека протоколов (например, TCP/IP), таким образом FireWall 1 располагается на самом ниж нем программном уровне.

Работая на этом уровне. Checkpoint FireWali—1 гарантирует, что Инспекционный Модуль контролирует и про веряет весь входной и выходной график на всех интерфейсах. Ни один из входящих пакетов не будет обрабо тан стеками протоколов более высоких уровней, независимо от того, какой протокол или приложение исполь зует этот пакет, до тех пор, пока Инспекционный Модуль не проверит пакет на соответствие стратегии защиты.

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

Checkpoint FireWall 1 понимает внутренние структуры семейства IP протоколов и приложений, сформирован ные на их верхних уровнях. Для stateless протоколов типа UDP и RPC, Checkpoint FireWall 1 выделяет и сохра няет контекстные данные (“UDP (User Datagram Protocol)” и “RPC (Remote Procedure Call)”). Он способен из влекать данные из пакетов и сохранять их в случае, если приложение не обеспечивает эту возможность. Кро ме того. Checkpoint FireWall 1 способен динамически разрешать и запрещать соединения по мере необходи мости. Описанные гибкие динамические возможности разработаны для обеспечения самого высокого уров ня защиты для сложных протоколов. Однако существует и возможность их отключения, если это необходимо. Способность Checkpoint FireWall—1 работать с данными внутри пакета предоставляет возможность разре шать некоторые команды внутри приложения и запрещать другие. Например, Checkpoint FireWall 1 разре шит прохождения ping ICMP, в то время как переадресация будет запрещена; или разрешит функцию get SNMP, a put запретит, и так далее. Checkpoint FireWall 1 может сохранять и получать значения в таблицах (динамический контекст) и выполнять логические или арифметические операции над данными в любой части пакета. В дополнение к операциям из стратегии защиты, пользователь может создать свои собствен ные выражения и таблицы.

48.18

Конфигурирование Firewall

Пакеты, которые стратегия защиты явно не разрешает, просто уничтожаются в соответствии с принципом “Что явно не разрешено, то запрещено”.

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

•eitherbound — Пакеты инспектируются на интерфейсе: при входе и выходе из системы

•inbound — Пакеты инспектируются на входе в систему firewall

•outbound — Пакеты инспектируются на выходе из системы firewall

Обычно на шлюзах пакеты просматриваются на входе, хотя возможно проверять пакеты и на выходе.

Аутентификация Аутентификация пользователей

Checkpoint FireWall—1 позволяет определять стратегию защиты на уровне пользователей, где проверяется не только источник пакета, адресат и номер порта, но, кроме того, аутентифицируются отдельные пользова тели интерактивных сеансов (TELNET, RLOGIN, HTTP и FTP).

Когда опция аутентификации пользователя разрешена в системе. Checkpoint FireWall 1 заменяет стандарт ные демоны на шлюзах с FireWall Модулем на специальные серверы безопасности Checkpoint FireWall 1. FireWall 1 (на gateway) перехватывает попытки пользователей запустить аутентифицированную сессию на сервере и “переправляет” соединение к подходящему серверу безопасности на мосте, который проводит аутен тификацию.

Когда сервер безопасности Checkpoint FireWall 1, выполняющийся на прикладном уровне, получает запрос на установление соединения, он инициализирует процедуру идентификации пользователя в соответствии с определенной для него схемой. Например, если установлен механизм авторизации Secur Id, то Checkpoint FireWall 1 демон запрашивает авторизацию от локального клиента АСЕ. Идентифицированный пользователь должен затем указать хост для интерактивного сеанса. Checkpoint FireWall 1 затем проверяет, определен ли данный хост как “разрешенное назначение” для данного пользователя.

Даже после того, как пользователь был идентифицирован, Checkpoint FireWall 1 не позволяет открыть инте рактивный сеанс непосредственно на указанной машине. Вместо этого сервер безопасности Checkpoint FireWall 1 запускает на шлюзе защищенный интерактивный сеанс на указанном компьютере. Пакеты интерак тивного сеанса инспектируются Модулем Проверки Checkpoint FireWall 1 при попадании на шлюз и переда ются далее в сервер безопасности FireWall—1 на прикладном уровне. После этого пакеты поступают снова в Модуль Проверки Checkpoint FireWall 1, который будет проверять их еще раз, прежде чем они продолжат путь на указанный компьютер. В каждом пункте маршрута пакеты могут регистрироваться и может быть выдано предупреждающее сообщение. Таким образом, интерактивный сеанс надежно защищается сервером безопас ности FireWall 1, но пользователь не чувствует этого, кроме момента регистрации при начальном входе в си стему, и имеет полную иллюзию работы непосредственно на нужном компьютере,

Хотя стратегия защиты выполнена на различных уровнях протокола IP, имеется только одна стратегия защи ты, одна База Правил, одна централизованная регистрация и механизм оповещения для всех уровней. Замечание — вдобавок к единой интегрированной стратегии безопасности, администратор системы может, если необходимо, поддерживать различные готовые базы правил, например, для различных времен суток.

Сервер безопасности HTTP

Сервер безопасности FireWall 1 HTTP обеспечивает механизм для идентификации пользователей услуг HTTP. Сервер безопасности HTTP Checkpoint FireWall l может защищать любое число серверов HTTP во внутренней сети и управлять доступом локальных пользователей ко внешним HTTP серверам.

Аутентификация клиента

Аутентификация Клиента работает с любыми протоколами и TELNET, FTP и HTTP в часности. Она обеспечива ет механизм, не зависящий от приложения и стандарта. Нет никакой необходимости вносить изменения в приложение, как для сервера, так и для клиента. Администратор может определять для каждого конкретного случая, какой должна быть процедура опознания, какой сервер и приложения доступны и в какое время, а также сколько сеансов разрешается. После начала сеанса, Checkpoint FireWall 1 SMLI технология обеспечит самую высокую эффективность работы. Никакие proxies не используются, поэтому очень высокие показате ли производительности достигаются даже на обычных рабочих станциях. Данное средство полностью интег рировано Базой Правил, графическим интерфейсом пользователя и средством Log Viewer.

Аутентификация сессий

Аутентификацию сессий можно использовать для аутентификации любого сервиса с точностью до порта. Аутентификация сессий действует следующим образом:

•Пользователь инициирует соединение прямо к серверу.

•Модуль FireWall подключается к Агенту Аутентификации Сессий, дающему необходимые для аутентифи кации данные.

Агент Аутентификации Сессий пользовательское приложение, которое взаимодействует с модулем FireWall, используя протокол аутентификации сессий FireWall 1. Агент Аутентификации Сессий может ра ботать на любом компьютере. На рис. 10, Агент Аутентификации Сессий показан работающим на клиен те, но он может работать на любом компьютере.

•Если аутентификация была успешна. Модуль FireWall разрешает установить соединение к серверу через gateway.

48.19

Конфигурирование Firewall

Agent

Рис. 10. Аутентификация Сессий

Шифрование

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

Решение Checkpoint FireWall-1

Checkpoint FireWall 1 обеспечивает безопасную двунаправленную связь через Internet и механизм шифрова ния и подписи для гарантии целостности данных и конфиденциальности при соединении Виртуальных Частных Сетей.

Checkpoint FireWall 1 обеспечивает все потребности защиты предприятия: Секретность подслушивание на линии невозможно Подлинность невозможны подстановки сетевых компьютеров

Целостность — подстановка и модификация данных на лету невозможна

Checkpoint FireWall—1 реализует единую, интегрированную стратегию защиты с распознаванием клиентов и шифрованием данных. Предлагая различные схемы шифрования и интегрированные системы распределения ключей, Checkpoint FireWall— 1 позволяет предприятию полностью использовать возможности Internet для ведения бизнеса, обеспечения связи, построения частных виртуальных сетей.

Checkpoint FireWall 1 поддерживает скорости шифрования более 10 Мбит/с на обычных настольных рабо чих станциях. Поставляется встроенный механизм управления ключами, также как и способность общать ся с certificate authority. Доступное управление полностью интегрировано в GUI редактор Базы Правил и Log Viewer.

FireWall Поддерживает три схемы шифрования:

1.FWZ, собственная схема шифрования FireWall 1

2.Manual IPSec, схема шифрования и аутентификации, использующая постоянные ключи

3.SKIP (Simple Key Management for Internet Protocols), разработанную Sun

Microsystems, которая добавляет к IPSec улучшенные ключи и механизм управления ключами

Связь между всеми компонентами схем шифрования, реализованных в FireWall 1, показана в табл. 14.

DES, FWZ1 и RC4 являются алгоритмами шифрования, используемыми для шифрования порции данных в па кете.

FireWall 1 обеспечивает полностью прозрачное выборочное шифрование для широкого спектра служб. Шифрование, дешифровка и управление ключами полностью интегрированы с другими возможностями FireWall—1.

Таблица 14.

Схемы шифрования

48.20

Конфигурирование Firewall

Пример конфигурации

Рисунок 11 описывает общую корпоративную сеть, где две частных сети соединены через Internet через шлюз FireWalI. HQ Станция Управления для обоих сетей. Частные сети (hq сеть и DMZnet) защищены шлюзом FireWalI, но внешняя часть сети — Internet — рассматривается как открытая и небезопасная.

Рис. 11. Конфигурация сети с двумя мостами

Области передачи шифрованной информации

Шлюзы выполняют шифрование для каждой из своих областей: для локальной вычислительной сети или груп пы сетей, которые защищаются шлюзом. За шлюзом, во внутренних сетях, пакеты не шифруются. Область шиф рования HQ состоит из HQnet и DMZnet, а область шифрования в Лондоне London net.

Если администратор системы определил, что связь между HQ и Лондоном должна быть зашифрована, Checkpoint FireWalI—1 будет шифровать пакеты, проходящие через gateway в Internet. Пакет, идущий от от дела Сбыта до Администрации, шифруется только на участке Лондон hq, но не шифруется на сегментах hq администрация и Лондон — сбыт.

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

Распределение ключей

Схема задания ключей для алгоритма шифрации основана на алгоритмах RSA и Diffie— Hellman. Станция уп равления обеспечивает каждый Gateway, управляемый ею:

•парой Diffie Hellman ключей

•выступает для Gateway в роли Certificate Authority

•шифрованной передачей (распределением) ключей на другие шлюзы

В начале шифрованного сеанса шлюз вычисляет сессионный ключ по алгоритму Diffie Hellman и затем на чинает шифрованную связь.

Шаг за шагом

Чтобы включить шифрование, Вы должны ответить на три вопроса:

1. Кто будет шифровать ?

Необходимо определить шифрующие шлюзы и их области шифрования. 2. Какие ключи шифрования ?

Определим ключи шифрования в окне управления ключами и сгенерируем для Gateway пару ключей по алго ритму Diffie Hellman.

3. Что будет шифроваться ?

Создайте правило в Базе Правил, в котором определите действие Encrypt в поле Action для связей между ком пьютерами предприятия.

Для получения дополнительной информации о криптографических свойствах FireWall—1 обратитесь к “Privacy in Public Networks Using Check Point FireWall—1”.

FireWall -1 SecuRemote

FireWall l SecuRemote позволяет пользователям мобильных и удаленных систем Microsoft Windows 95 и NT под соединяться к корпоративным сетям по телефонным линиям Internet — напрямую к серверу или через Internet—провайдеров — и работать с корпоративными данными также безопасно, как если бы они находи

48.21

Конфигурирование Firewall

лись под защитой Internet FireWall. FireWall—I SecuRemote продлит Virtual Private Network прямо до компь ютера удаленного пользователя.

FireWall l SecuRemote основана на технологии Кодировки Клиентов. FireWall l SecuRemote кодирует данные до того, как они покидают переносной компьютер, что гарантирует полную защиту для пользователей уда ленных и мобильных систем, использующих при удаленном доступе возможности FireWall l.

FireWall l SecuRemote осуществляет прозрачную кодировку всего графика TCP/IP. Для этого не надо менять сетевые приложения на ПК пользователя. FireWall—1 SecuRemote может работать с любым существующим сетевым адаптером и стеками протокола ТСРДР. ПК, на который устанавливается FireWall l SecuRemote, может быть подсоединен к нескольким офисам, использующим VPN.

Оператор системы защиты FireWall—1 может предоставить доступ для пользователей FireWall —1 SecuRemote при помощи стандартного редактора базы правил FireWall 1. После процедуры распознавания пользователя FireWall—1 SecuRemote, создается полностью прозрачное и защищенное соединение, при чем для FireWall 1 пользователь становится таким же объектом, как и любой другой пользователем Virtual Private Network. Администратор сети может усилить уровень защиты FireWall 1, используя, например, сер вера аутентификации, журналирование событий и сигналы тревоги для соединений FireWall—1 SecuRemote (так же как и для любого другого соединения).

Corporate Headquaters

Mango (FireWall-1 Management Station)

HP

Sun

FireWalled

Gateway

FireWalled

Gateway

NT

SecuRemote

User

Firewall

Gateway

...................

European Office

Рис. 12. Виртуальная Частная Сеть со внешними пользователями

FireWal l—1 SecuRemote имеет следующие возможности:

•поддерживает динамическую IP адресацию, необходимую для установления соединения по телефонным линиям

•использует мощную аутентификацию пользователей, используя алгоритмы Diffie — Hellman и RSA

•мощную систему кодировки при помощи FWZ1 или DES

Трансляция IP адресов

Потребность в трансляции IP адреса замена одного IP адреса в пакете другим IP адресом — возникает в двух случаях:

1. Если сетевой администратор хочет скрыть внутренние IP адреса сети от Internet

Причиной является то, что с точки зрения безопасности нет особой выгоды от общей доступности схемы внут ренней адресации сети.

48.22

Конфигурирование Firewall

2. Если IP адреса внутренней сети недопустимы для Internet. Например, эти адреса принадлежат другой сети. Такая ситуация может возникнуть по историческим причинам: внутренняя сеть не была первоначально со единена с Internet и IP адреса были выбраны произвольно без каких либо соглашений. Если такая сеть затем соединяется с Internet, внутренние IP адреса , используемые ранее, не могут использоваться для внешних связей. А изменение этих адресов может быть трудоемко или невозможно.

Влюбом случае внутренние IP адреса не могут использоваться для доступа в Internet. Однако, доступ в Internet должен быть все же предусмотрен из внутренних сетей с недопустимыми или секретными IP адресами. Application Gateway (proxies) исторически служил как частичное решение этих проблем. Например, чтобы скрыть внутренний IP адрес, пользователь может открыть сессию TELNET на шлюзе и оттуда продолжить ра боту в Internet через специальный proxy. Checkpoint FireWall 1 может быть легко настроен, для обеспечения подобной схемы работы, предоставляя широкий набор услуг (FTP, TELNET, HTTP, и т.д.). Кроме того, Checkpoint FireWall 1 дополняет эту схему, обеспечивая идентификацию пользователя на шлюзе.

С другой стороны, proxy имеет и недостатки:

• Proxy написаны под конкретное приложение, поэтому невозможно использовать приложения, которые не имеют соответствующего proxy.

• Proxy не прозрачен, так что даже зарегистрированные удаленные пользователи должны работать через приложение на шлюзе, что накладывает большие требования на производительность компьютера шлю за. Основная задача proxy после установки соединения — передать пакеты на прикладном уровне, что является неэффективным использованием ресурсов.

• Трудно реализовать хороший proxy для протоколов, отличных от TCP.

ВCheckpoint FireWall 1 реализован другой механизм, обеспечивающий прозрачную и общую для всех приложе ний возможность трансляции адресов, что обеспечивает полное и эффективное решение. Администратор оп ределяет, какой внутренний IP адрес надо скрыть и как преобразовать его в зарегистрированный IP адрес, ви димый в Internet. В то же время, внутренние компьютеры могут быть сконфигурированы так, чтобы быть дос тупными из Internet, даже если их внутренние IP адреса недопустимы для Internet. Таким образом Checkpoint FireWall—1 обеспечивает как маскировку IP адреса, так и статическую Трансляцию Адреса, предлагая неогра ниченные возможности по установлению соединений в Internet для внутренних клиентов при максимальной производительности, даже если шлюз стандартная рабочая станция.

Трансляция Адреса может использоваться для “однонаправленной маршрутизации” так, чтобы не существо вало маршрута снаружи во внутреннюю сеть или к центральным компьютерам.

Например, на рис.13 показано, как Checkpoint FireWall 1 транслирует запрещенные внутренние адреса в диа пазоне 200.0.0.100 200.0.0.200 в допустимые адреса 199.203.73.15 199.203.73.115.

Графический интерфейс значительно упрощает задание правил трансляции адресов, и позволяет более по нятно задавать сложные правила.

Кроме этого, существует возможность автоматической генерации правил трансляции адресов

Рис.13 Трансляция адресов FireWall—1

Исходящие соединения FTP

Хотя Протокол Передачи файлов (FTP) один из наиболее используемых и давно существующих TCP—прото колов в Internet, защита графика FTP сталкивается с рядом трудностей. После того, как клиент инициализи рует в FTP сеансе передачу данных, сервер устанавливает новый (обратный) канал для клиента. Это соедине ние исходит от сервера (за границами FireWall) к динамически назначаемому номеру порта на клиентской машине. Номер порта не известен заранее и клиент часто открывает/закрывает канал, назначая при этом близкие номера портов. Если просто открыть весь диапазон непривилегированных портов (> 1023) для вхо дящих соединений, как это делают многие из систем FireWall, это подвергнет внутреннюю сеть опасности. За счет этого обходного пути было осуществлено много успешных взломов.

Checkpoint FireWall 1 контролирует сеанс FTP, исследуя данные прикладного уровня FTP. Когда клиент про сит сервер установить обратное соединение, клиент генерирует при этом команду FTP PORT, Checkpoint FireWall 1 извлекает номер порта из запроса. Далее IP—адресат (клиент и сервер) и оба номера порта за поминаются в списке ждущего запроса для данных FTP. Когда сервер предпринимает попытку открыть со единение для передачи данных FTP, Checkpoint FireWall 1 проверяет список и устанавливает, что эта по пытка — ответ на разрешенный запрос. Список соединений поддерживается динамически так, чтобы только необходимые порты FTP были открыты и только в течение сеанса передачи данных FTP. Как только сеанс закрыт, порты блокируются, гарантируя надежную защиту.

Сеансы Real Audio и VDOLive обрабатываются аналогичным образом.

48.23

Конфигурирование Firewall

UDP - приложения

Протоколы типа UDP (User Datagram Protocol) и RFC (Remote Procedure Call) создают специальные проблемы для систем защиты, потому что они не имеют контекста (stateless). Checkpoint FireWall—1 защищает эти про токолы, создавая и динамически сохраняя контекстные состояния на основе информации в пакетах и опера ционной системе.

UDP (User Datagram Protocol)

UDP приложения (типа WAIS, Archie и DNS) трудно фильтровать простыми методами, так как в UDP не имеется никакого различия между запросом и ответом. Раньше был выбор: либо полностью блокировать сеансы UDP, либо открывать большой блок диапазона UDP для двунаправленной связи и, таким образом, подвергать внут реннюю сеть опасности.

Checkpoint FireWall—1 защищает UDP приложения, организуя виртуальное соединение поверх соединения UDP. Checkpoint FireWall—1 поддерживает информацию о состоянии каждого сеанса, идущего через шлюз. Каждый разрешенный пакет UDP запроса, пересекающий FireWall, записывается, а пакеты UDP, следующие в противоположном направлении, проверяются на соответствие списку отложенных сеансов для гарантии того, что данный пакет находится в разрешенном контексте. Пакет, который является подлинным ответом на зап рос, пропускается, остальные блокируются. Если в течение определенного времени ответ отсутствует, систе ма считает сессию завершенной и блокирует ее. В этом случае все атаки блокированы, хотя UDP приложения могут использоваться во внешних соединениях.

RFC (Remote Procedure Call)

Простой мониторинг номеров портов терпит неудачу для RPC, так как RPC приложения не используют опреде ленные заранее номера портов. Распределение портов происходит динамически и часто меняется во времени. Checkpoint FireWall 1 динамически отслеживает номера портов RPC, контролируя запросы к программам portmapper. Checkpoint FireWall—1 постоянно контролирует запросы к программам portmapper серверов, за полняет кэш таблицы, которые содержат номера программ RCP и связанные с ними номера портов и адреса серверов.

Всякий раз, когда Checkpoint FireWall 1 проверяет правило, в котором описано RPC приложение, система запра шивает кэш состояний, сравнивая номера портов в пакете и кэш, проверяя, что номер программы, привязанный к порту, соответствует определенному в правиле.

Если номер порта в пакете не найден в кэше (что может происходить, когда приложение полагается на зна ние зарезервированных номеров портов и инициализирует связь без обращения к portmapper). Checkpoint FireWall—1 выдает собственный запрос к portmapper и сверяет номер программы, привязанной к порту.

Эффективность

Простая и эффективная архитектура Инспекционного Модуля предлагает оптимальную производительность за счет таких решений, как:

•Выполнение внутри ядра операционной системы требует незначительных затрат производительности при обработке. Не требуется переключение контекста, что существенно снижает затраты на обработку.

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

•Обобщенные и простые инспекционные механизмы объединены с оптимизатором сценариев проверки пакетов, чтобы гарантировать оптимальность их использования на современных процессорах и опера ционных системах.

Firewall/Plus

FireWall/Plus for Windows NT gроизводство фирмы Network 1 Software&Technology, Inc.

Назначение:

•защита ресурсов корпоративных сетей от атак со стороны Internet

•реализация мер безопасности (для выделенного сервера или группы серверов) внутри корпоративной сети

•разделение сегментов внутренней сети для предотвращения попыток НСА со стороны внутреннего пользо вателя

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

Такая возможность, не предусмотренная ни в одном другом продукте данного класса, делает применение FireWall/ Plus особенно удобным для решения задач разделения сегментов корпоративной сети, в которой используются продукты, работающие со стеками TCP/IP, IPX, DECNet протоколов. Механизм описания протоколов прикладно го уровня позволяет создать уникальные схемы разграничения доступа пользователей, например, к базам дан ных.

FireWall/Plus обеспечивает безопасную работу с Web, FTP, URL, приложениями ActiveX и Java, a также с элек тронной почтой.

Экран может быть включен в сеть двумя способами:

48.24

Конфигурирование Firewall

•по схеме “dual homed gateway” двухпортовый шлюз (рис. 14)

•непосредственно на защищаемом сервере (рис. 15)

Internet Концентратор

FireWall/Plus

Сервер

Маршрутизатор

Рис.14

Концентратор

Рис. 15

FireWall/Plus предназначен для обнаружения и борьбы со следующими атаками:

•Определение номера начального пакета соединения TCP

•Атаки на аутентификацию сервера

•Атаки на протокол finger (со стороны внешней сети и изнутри корпоративной сети)

•Незаконная переадресация

•Атаки на DNS доступ

•Атаки на FTP аутентификацию

•Атаки на удаленную перезагрузку

•Подмена IP адресов сети

•Спуфинг МАС адреса

•Атаки на доступность (шторм запросов)

•Атаки на резервный порт сервера

•Атаки с помощью сервисов удаленного доступа

•Атаки на анонимный FTP доступ

•Атаки на несанкционированную пересылку файлов

В Firewall/Plus применяется комбинация механизма, используемого для фильтрации пакетов, и методов, за ложенных в Stateful Inspection. Весь входящий и исходящий трафик проходит тщательную проверку и лишь затем отправляется к адресату. Контроль реализован на уровне кадров, пакетов, каналов и приложений (для каждого протокола). Если трафик не проходит проверку на одном из указанных уровней, то он отбрасыва ется, а запись об этом событии заносится в журнал.

48.25

Конфигурирование Firewall

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

После установки FireWall/Plus в системе присутствуют необходимые для защиты фильтры, которые могут быть вклю чены/отключены администратором, а также изменены, и дополнены новыми специфическими фильтрами. FireWall/Ptus обеспечивает безопасную работу с Web, FTP, URL, приложениями ActiveX и Java, а также с элек тронной почтой.

Продукт поставляется в 2 х версиях:

1.INTRANET Server версия — устанавливается непосредственно на сервер Windows NT; защищает один выде ленный сервер.

2.Enterprise версия — предназначена для защиты корпоративной сети от несанкционированных действий со стороны внешней сети или для разделения сегментов корпоративной сети. Продукт включается в сеть как двухпортовый шлюз (конфигурация dual homed gateway).

FireWall/Plus работает в режиме ядра NT, вследствие чего превосходит по производительности и безопасности меж сетевые экраны, функционирующие в обычном режиме. Режим ядра предоставляет возможность управлять сете вым графиком еще до начала его обработки средствами операционной системы. Продукт позволяет производить администрирование как локально, так и по сети.

FireWatl/Plus поддерживает три метода преобразования сетевых адресов: “один к одному”, “один ко многим”, “многие ко многим”. FireWall/Plus не нужен собственный IP адрес. Эта особенность делает его полностью про зрачным в сети и практически неуязвимым при различных атаках.

Являясь официальным представителем компании NETWORK 1 на территории России, ООО “Конфидент” предлага ет свои услуги по установке и сервисному обслуживанию FireWall/Plus, а также консультирование по вопросам обес печения безопасности корпоративных сетей.

48.26

Инструментальный анализ риска. Средства аудита

(сканеры безопасности)

49.1

Инструментальный анализ риска. Средства аудита (сканеры безопасности)

Содержание

49.2

Инструментальный анализ риска. Средства аудита (сканеры безопасности)

Введение

В последнее время увеличилось число публикаций (в основном, зарубежных), посвященных такому новому направлению в области защиты информации, как адаптивная безопасность сети. Это направление состоит из двух основных технологий анализ защищенности (security assessment) и обнаружение атак (intrusion detection). Именно первой технологии и посвящена данная статья.

Сеть состоит из каналов связи, узлов, серверов, рабочих станций, прикладного и системного программного обеспечения, баз данных и т.д. Все эти компоненты нуждаются в оценке эффективности их защиты. Средства анализа защищенности исследуют сеть и ищут “слабые” места в ней, анализируют полученные результаты и на их основе создают различного рода отчеты. В некоторых системах вместо “ручного” вмешательства со сто роны администратора найденная уязвимость будет устраняться автоматически (например, в системе System Scanner). Перечислим некоторые из проблем, идентифицируемых системами анализа защищенности:

•“люки” в программах (back door) и программы типа “троянский конь”;

•слабые пароли;

•восприимчивость к проникновению из незащищенных систем;

•неправильная настройка межсетевых экранов, Web серверов и баз данных;

•и т.д.

Технология анализа защищенности является действенным методом реализации политики сетевой безопас ности прежде, чем осуществится попытка ее нарушения снаружи или изнутри организации.

Очень часто пишут об уникальных возможностях систем анализа защищенности (сканерах), подводя читате лей к убеждению, что эти системы являются панацеей от всех бед, и что они позволяют обнаруживать все вновь обнаруживаемые уязвимости. Но когда пользователи сталкиваются с ситуацией, которую можно опи сать вопросом: “Я вчера прочитал в Bugtraq про новую уязвимость в моей операционной системе. Почему сетевой сканер безопасности ее не обнаруживает?”, то они начинают обвинять системы анализа защищен ности во всех своих бедах. А ответ на заданный вопрос очень прост. В базе данных уязвимостей системы ана лиза защищенности этой уязвимости пока нет. Это один из аспектов, присущий всем системам анализа защи щенности. Они предназначены для обнаружения только известных уязвимостей, описание которых есть у них в базе данных. В этом они подобны антивирусным системам, которым для эффективной работы необходимо постоянно обновлять базу данных сигнатур. Данное занятие построено на материалах фирмы Информзащи та, которая имеет большой практический опыт применения сканеров безопасности компании Internet Security Systems – одного из лидеров этого сегмента рынка безопасности.

Функционировать такие средства могут на сетевом уровне (network based), уровне операционной системы (host based) и уровне приложения (application based). Наибольшее распространение получили средства ана лиза защищенности сетевых сервисов и протоколов. Связано это, в первую очередь, с универсальностью ис пользуемых протоколов. Изученность и повсеместное использование таких протоколов, как IP, TCP, HTTP, FTP, SMTP и т.п. позволяют с высокой степенью эффективности проверять защищенность информационной сис темы, работающей в данном сетевом окружении. Вторыми по распространенности являются средства анали за защищенности операционных систем (ОС). Связано это также с универсальностью и распространенностью некоторых операционных систем (например, UNIX и Windows NT). Однако из за того, что каждый производи тель вносит в операционную систему свои изменения (ярким примером является множество разновидностей ОС UNIX), средства анализа защищенности ОС анализируют в первую очередь параметры, характерные для всего семейства одной ОС. И лишь для некоторых систем анализируются специфичные для нее параметры. Средств анализа защищенности приложений на сегодняшний день не так много, как этого хотелось бы. Такие средства пока существуют только для широко распространенных прикладных систем, типа Web броузеры (Netscape Navigator, Microsoft Internet Explorer), СУБД (Microsoft SQL Server, Sybase Adaptive Server) и т.п.

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

Поскольку наибольшее распространение получили средства, функционирующие на уровне сети (системы SATAN, Internet Scanner, CyberCop Scanner, NetSonar и т.д.), то основное внимание будет уделено именно им.

1. Механизмы работы сканеров

Существует два основных механизма, при помощи которых сканер проверяет наличие уязвимости сканиро вание (scan) и зондирование (probe).

Сканирование механизм пассивного анализа, с помощью которого сканер пытается определить наличие уяз вимости без фактического подтверждения ее наличия по косвенным признакам. Этот метод является наи более быстрым и простым для реализации. В терминах компании ISS данный метод получил название “логи ческий вывод” (inference). Согласно компании Cisco, этот процесс идентифицирует открытые порты, найден ные на каждом сетевом устройстве, и собирает связанные с портами заголовки (banner), найденные при ска нировании каждого порта. Каждый полученный заголовок сравнивается с таблицей правил определения се

49.3

Инструментальный анализ риска. Средства аудита (сканеры безопасности)

тевых устройств, операционных систем и потенциальных уязвимостей. На основе проведенного сравнения делается вывод о наличии или отсутствии уязвимости.

Зондирование механизм активного анализа, который позволяет убедиться, присутствует или нет на анали зируемом узле уязвимость.Зондирование выполняется путем имитации атаки, использующей проверяемую уязвимость. Этот метод более медленный, чем “сканирование”, но почти всегда гораздо более точный, чем он. В терминах компании ISS данный метод получил название “подтверждение” (verification). Согласно ком пании Cisco, этот процесс использует информацию, полученную в процессе сканирования (“логического вы вода”), для детального анализа каждого сетевого устройства. Этот процесс также использует известные ме тоды реализации атак для того, чтобы полностью подтвердить предполагаемые уязвимости и обнаружить другие уязвимости, которые не могут быть обнаружены пассивными методами, например, подверженность атакам типа “отказ в обслуживании” (“denial of service”).

На практике указанные механизмы реализуются следующими несколькими методами.

“Проверка заголовков” (banner check)

Указанный механизм представляет собой ряд проверок типа “сканирование” и позволяет делать вывод об уязвимости, опираясь на информацию в заголовке ответа на запрос сканера. Типичный пример такой про верки анализ заголовков программы Sendmail или FTP сервера, позволяющий узнать их версию и на основе этой информации сделать вывод о наличии в них уязвимости.

Наиболее быстрый и простой для реализации метод проверки присутствия на сканируемом узле уязвимости. Однако за этой простотой скрывается немало проблем.

Эффективность проверок заголовков достаточно эфемерна. И вот почему. Во первых, вы можете изменить текст заголовка, предусмотрительно удалив из него номер версии или иную информацию, на основании ко торой сканер строит свои заключения. И хотя такие случаи исключительно редки, пренебрегать ими не сто ит. Особенно в том случае, если у вас работают специалисты в области безопасности, понимающие всю опас ность заголовков “по умолчанию”. Во вторых, зачастую, версия, указываемая в заголовке ответа на запрос, не всегда говорит об уязвимости программного обеспечения. Особенно это касается программного обеспе чения, распространяемого вместе с исходными текстами (например, в рамках проекта GNU). Вы можете са мостоятельно устранить уязвимость путем модификации исходного текста, при этом забыв изменить номер версии в заголовке. И в третьих, устранение уязвимости в одной версии еще не означает, что в следующих версиях эта уязвимость отсутствует.

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

“Активные зондирующие проверки” (active probing check)

Также относятся к механизму “сканирования”. Однако они основаны не на проверках версий программного обеспечения в заголовках, а на сравнении “цифрового слепка” (fingerprint) фрагмента программного обес печения со слепком известной уязвимости. Аналогичным образом поступают антивирусные системы, срав нивая фрагменты сканируемого программного обеспечения с сигнатурами вирусов, хранящимися в специа лизированной базе данных. Разновидностью этого метода являются проверки контрольных сумм или даты сканируемого программного обеспечения, которые реализуются в сканерах, работающих на уровне опера ционной системы.

Специализированная база данных (в терминах компании Cisco база данных по сетевой безопасности) со держит информацию об уязвимостях и способах их использовании (атаках). Эти данные дополняются сведе ниями о мерах их устранения, позволяющих снизить риск безопасности в случае их обнаружения. Зачастую эта база данных используется и системой анализа защищенности и системой обнаружения атак. По крайней мере, так поступают компании Cisco и ISS.

Этот метод также достаточно быстр, но реализуется труднее, чем “проверка заголовков”.

“Имитация атак” (exploit check)

Перевода термина “exploit” в российских публикациях я нигде не встречал и эквивалента в русском языке также не нашел. Поэтому воспользуюсь переводом “имитация атак”. Данные проверки относятся к механиз му “зондирования” и основаны на эксплуатации различных дефектов в программном обеспечении.

Некоторые уязвимости не обнаруживают себя, пока вы не “подтолкнете” их. Для этого против подозритель ного сервиса или узла запускаются реальные атаки. Проверки заголовков осуществляют первичный осмотр сети, а метод “exploit check”, отвергая информацию в заголовках, позволяет имитировать реальные атаки, тем самым с большей эффективностью (но меньшей скоростью) обнаруживая уязвимости на сканируемых узлах. Имитация атак является более надежным способом анализа защищенности, чем проверки заголовков, и обычно более надежны, чем активные зондирующие проверки.

Однако существуют случаи, когда имитация атак не всегда может быть реализована. Такие случаи можно раз делить на две категории: ситуации, в которых тест приводит к “отказу в обслуживании” анализируемого узла или сети, и ситуации, при которых уязвимость в принципе не годна для реализации атаки на сеть.

49.4

Инструментальный анализ риска. Средства аудита (сканеры безопасности)

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

Однако, есть некоторые уязвимости (например, проверка подверженности атакам типа “Packet Storm”), кото рые просто не могут быть протестированы без возможного выведения из строя сервиса или компьютера. В этом случае разработчики поступают следующим образом, по умолчанию такие проверки выключены и пользователь может сам включить их, если желает. Таким образом, например, реализованы системы CyberCop Scanner и Internet Scanner. В последней системе такого рода проверки выделены в отдельную категорию “Denial of service” (“Отказ в обслуживании”). При включении любой из проверок этой группы система Internet Scanner выдает сообщение “WARNING: These checks may crash or reboot scanned hosts” (“Внимание: эти проверки могут вывести из строя иди перезагрузить сканируемые узлы”).

2. Этапы сканирования

Практически любой сканер проводит анализ защищенности в несколько этапов:

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

2.Обнаружение потенциальных уязвимостей. Сканер использует описанную выше базу данных для сравне ния собранных данных с известными уязвимостями при помощи проверки заголовков или активных зонди рующих проверок. В некоторых системах все уязвимости ранжируются по степени риска. Например, в сис теме NetSonar уязвимости делятся на два класса: сетевые и локальные уязвимости. Сетевые уязвимости (например, воздействующие на маршрутизаторы) считаются более серьезными по сравнению с уязвимос тями, характерными только для рабочих станций. Аналогичным образом “поступает” и Internet Scanner. Все уязвимости в нем делятся на три степени риска: высокая (High), средняя (Medium) и низкая (Low).

3.Подтверждение выбранных уязвимостей. Сканер использует специальные методы и моделирует (имити рует) определенные атаки для подтверждения факта наличия уязвимостей на выбранных узлах сети.

4.Генерация отчетов. На основе собранной информации система анализа защищенности создает отчеты, описывающие обнаруженные уязвимости. В некоторых системах (например, Internet Scanner и NetSonar) отчеты создаются для различных категорий пользователей, начиная от администраторов сети и заканчи вая руководством компании. Если первых в первую очередь интересуют технические детали, то для ру ководства компании необходимо представить красиво оформленные с применением графиков и диаг рамм отчеты с минимумом подробностей. Немаловажным аспектом является наличие рекомендаций по устранению обнаруженных проблем. И здесь по праву лидером является система Internet Scanner, кото рая для каждой уязвимости содержит пошаговые инструкции для устранения уязвимостей, специфичные для каждой операционной системы. Во многих случаях отчеты также содержат ссылки на FTP или Web сервера, содержащие patch’и и hotfix’ы, устраняющие обнаруженные уязвимости.

5.Автоматическое устранение уязвимостей. Этот этап очень редко реализуется в сетевых сканерах, но ши роко применяется в системных сканерах (например, System Scanner). При этом данная возможность мо жет реализовываться по разному. Например, в System Scanner создается специальный сценарий (fix script), который администратор может запустить для устранения уязвимости. Одновременно с созданием этого сценария создается и второй сценарий, отменяющий произведенные изменения. Это необходимо в том случае, если после устранения проблемы нормальное функционирование узла было нарушено. В

других системах возможности “отката” не существует.

В любом случае у администратора, осуществляющего поиск уязвимостей, есть несколько вариантов исполь зования системы анализа защищенности:

•Запуск сканирования только с проверками на потенциальные уязвимости (этапы 1,2 и 4). Это дает пред варительное ознакомление с системами в сети. Этот метод является гораздо менее разрушительным по сравнению с другими и также является самым быстрым.

•Запуск сканирования с проверками на потенциальные и подтвержденные уязвимости. Этот метод может вызвать нарушение работы узлов сети во время реализации проверок типа “exploit check”.

•Запуск сканирования с вашими пользовательскими правилами для нахождения конкретной проблемы.

•Все из вышеназванного.

Особенности применения

Если сканер не находит уязвимостей на тестируемом узле, то это еще не значит, что их нет. Просто сканер не нашел их. И зависит это не только от самого сканера, но и от его окружения. Например, если Вы тестируете сервис Telnet или FTP на удаленной машине, и сканер сообщает Вам, что уязвимостей не обнаружено это может значить не только, что уязвимостей нет, а еще и то, что на сканируемом компьютере установлен, на пример, TCP Wrapper. Да мало ли еще чего? Вы можете пытаться получить доступ к компьютеру через межсе тевой экран или попытки доступа блокируются соответствующими фильтрами у провайдера и т.д. Для ОС

49.5

Инструментальный анализ риска. Средства аудита (сканеры безопасности)

Windows NT характерен другой случай. Сканер пытается дистанционно проанализировать системный реестр (registry). Однако в случае запрета на анализируемом узле удаленного доступа к реестру сканер никаких уяз вимостей не обнаружит. Существуют и более сложные случаи. И вообще различные реализации одного итого же сервиса по разному реагируют на системы анализа защищенности. Очень часто на практике можно уви деть, что сканер показывает уязвимости, которых на анализируемом узле нет. Это относится к сетевым ска нерам, которые проводят дистанционный анализ узлов сети. И удаленно определить, существует ли в дей ствительности уязвимость или нет, практически невозможно. В этом случае можно порекомендовать исполь зовать систему анализа защищенности на уровне операционной системы, агенты которой устанавливаются на каждый контролируемый узел и проводят все проверки локально.

Для решения этой проблемы некоторые компании производители пошли по пути предоставления своим пользователям нескольких систем анализа защищенности, работающих на всех указанных выше уровнях, сетевом, системном и уровне приложений. Совокупность этих систем позволяет с высокой степенью эффек тивности обнаружить практически все известные уязвимости. Например, компания Internet Security Systems предлагает семейство SAFEsuite, состоящее из четырех сканеров: Internet Scanner, System Scanner, Security Manager и Database Scanner. В настоящий момент это единственная компания, которая предлагает системы анализа защищенности, функционирующие на всех трех уровнях информационной инфраструктуры. Другие компании предлагают или два (Axent) или, как правило, один (Network Associates, NetSonar и др.) сканер.

Компания Cisco, предлагающая только систему анализа защищенности на уровне сети, пошла другим путем для устранения проблемы ложного срабатывания. Она делит все уязвимости на два класса:

•Потенциальные вытекающие из проверок заголовков и т.н. активных “подталкиваний” (nudge) анали зируемого сервиса или узла. Потенциальная уязвимость, возможно, существует в системе, но активные зондирующие проверки не подтверждают этого.

•Подтвержденные выявленные и существующие на анализируемом хосте.

Проверки на потенциальную уязвимость проводятся через коллекцию заголовков и использование “несиль ных подталкиваний”. “Подталкивание” используется для сервисов, не возвращающих заголовки, но реагиру ющих на простые команды, например, посылка команды HEAD для получения версии HTTP сервера. Как толь ко эта информация получена, система NetSonar использует специальный механизм (rules engine), который реализует ряд правил, определяющих, существует ли потенциальная уязвимость.

Таким образом, администратор знает, какие из обнаруженных уязвимостей действительно присутствуют в си стеме, а какие требуют подтверждения.

Однако в данном случае остаются уязвимости, с трудом обнаруживаемые или совсем не обнаруживаемые че рез сеть. Например, проверка “слабости” паролей, используемых пользователями и другими учетными запи сями. В случае использования сетевого сканера вам потребуется затратить очень много времени на удален ную проверку каждой учетной записи. В то же время, аналогичная проверка, осуществляемая на локальном узле, проводится на несколько порядков быстрее. Другим примером может служить проверка файловой сис темы сканируемого узла. Во многих случаях ее нельзя осуществить дистанционно.

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

Многие сканеры используют более чем один метод проверки одной и той же уязвимости или класса уязвимо стей. Однако в случае большого числа проверок использование нескольких методов поиска одной уязвимо сти привносит свои проблемы. Связано это со скоростью проведения сканирования.

Например, различие между системами CyberCop Scanner и Internet Scanner в том, что разработчики из NAI никогда не добавят в свой продукт проверку, если не могут с уверенностью сказать, что проверка надежно обнаруживает уязвимость. В то время как разработчики ISS пополняют свою базу даже в том случае, если их проверка обнаруживает уязвимость с некоторой точностью. Затем, уже после выпуска системы, происходит возврат к разработанным проверкам, их улучшение, добавление новых механизмов осуществления проверок той же уязвимости для повышения достоверности, и т.д. Достаточно спорный вопрос, что лучше. С одной сто роны лучше, когда вы с уверенностью можете сказать, что на анализируемом узле определенной уязвимости нет. С другой, даже если существует хоть небольшой шанс, что вы можете обнаружить уязвимость, то надо этим шансом воспользоваться. В любом случае наиболее предпочтительным является проверка типа “имита ция атак”, которая обеспечивает наибольший процент точного обнаружения уязвимостей.

Не все проверки, разработанные в лабораторных условиях, функционируют так, как должны. Даже, несмотря на то, что эти проверки тестируются, прежде чем будут внесены в окончательную версию сканера. На это могут влиять некоторые факторы:

•Особенности конфигурации пользовательской системы.

•Способ, которым был скомпилирован анализируемый демон или сервис.

•Ошибки удаленной системы.

•И т.д.

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

49.6

Инструментальный анализ риска. Средства аудита (сканеры безопасности)

Разница в реализации

Системы различных производителей могут использовать различные методы поиска одной и той же уязвимо сти, что может привести к ее нахождению в случае использования одного средства и ненахождения в слу чае другого. Хорошую ассоциацию приводит ведущий разработчик системы Internet Scanner Девид ЛеБлан. “Если вы спросите меня дома мой товарищ или нет, я просто позвоню ему. Если его телефон не отвечает, то я позвоню вам и сообщу, что его нет дома. Затем вы идете к нему домой, стучите в дверь и он отвечает. Не называйте меня лжецом только из за того, что то, что я пытался сделать, не сработало. Возможно, я был не прав или необходимо было использовать другие методы, но я пытался сделать то, что считал нужным”. Так и со средствами поиска уязвимостей.

Кроме того, если в созданном отчете не сказано о той или иной уязвимости, то иногда стоит обратиться к жур налам регистрации (log) системы анализа защищенности. В некоторых случаях, когда сканер не может со 100% ой уверенностью определить наличие уязвимости, он не записывает эту информацию в отчет, однако сохра няет ее в логах. Например, анализ и разбор поля sysDescr в журнале регистрации системы Internet Scanner существенно помогает во многих спорных случаях.

Существуют различия и между тем, как влияет одна и та же проверка на различные версии сервисов в раз личных операционных системах. Например, использование учетной записи halt для демона Telnet на некото рых компьютерах под управлением Unix или Windows NT не приведет к плачевным последствиям, в то время как на старых версиях Unix это вызовет запуск команды /bin/halt при попытке доступа к удаленной системе с использованием этой учетной записи.

Перспективы развития

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

Автоматическое обновление уязвимостей

До недавнего времени пополнение сканера новыми уязвимостями проводилось достаточно редко (1 раз в ме сяц и реже). При этом под пополнением понималось обновление всей системы анализа защищенности, т.е. по лучение новой версии программного обеспечения.

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

Единый формат базы уязвимостей

В целях унификации и возможной интеграции систем анализа защищенности в настоящий момент ведутся работы по созданию единого для всех сканеров формата базы уязвимостей. И хотя работа эта только нача лась и ей далеко до своего завершения, первые шаги уже сделаны. Например, лаборатория COAST в универ ситете Purdue разработала проект такой базы данных. Одна из проблем, с которой пришлось столкнуться исследователям, это описание уязвимостей и их проверок (атак).

Языки описания уязвимостей и проверок

Попытки добавить механизмы описания уязвимостей и проверок в системы анализа защищенности велись давно. Они предпринимались практически всеми компаниями разработчиками. Первая такая попытка была предпринята Витсом Венема и Деном Фармером разработчиками системы SATAN. Описание новых уязвимо стей, точнее, их проверок, осуществлялось при помощи языка Perl. Это достаточно нетривиальная задача тре бовала обширных знаний как языка Perl, так и архитектуры стека протоколов TCP/IP и сканируемой операци онной системы. По этому же пути (использование Perl) пошли разработчики системы WebTrends Security Analyzer. В приложении 1 приведен пример проверки, позволяющей определить тип операционной системы сканируемого узла. Язык Perl, наряду с языком C, используется и в системе Internet Scanner. Причем помимо возможностей, встроенных в саму систему Internet Scanner, компания ISS поставляет отдельную систему опи сания атак APX (Advanced Packets eXchange).

Другим языком, используемым при описании осуществляемых проверок, стал Tcl. Модификации этого языка ис пользуются в системах APX (бесплатное приложение к системе Internet Scanner), Security Manager и CyberCop Scanner. Компания Network Associates последовала примеру компании ISS и выделила механизм описания уяз вимостей в отдельную систему CyberCop CASL (Custom Audit Scripting Language). Также как и APX, система CyberCop CASL может функционировать под управлением ОС Windows NT и Unix (Linux для CASL и Solaris для APX).

В системах APX и CASL описываются параметры сетевых пакетов, при помощи которых моделируются различ ные атаки. К таким параметрам можно отнести флаги в заголовке IP пакета, номера портов в заголовке TCP пакета, поля данных в пакетах различных протоколов и т.д. В качестве примера (Приложение 2) можно при вести проверку возможности осуществления подмены пакетов (Spoofing).

49.7

Инструментальный анализ риска. Средства аудита (сканеры безопасности)

Однако наиболее удобным с точки зрения конечного пользователя (не программиста) является язык VDL (Vulnerability Descriptive Language) и VEL (Vulnerability Exploit Language), разработанный компанией Cisco. Проверки, описываемые этими языками, основаны на простых логических утверждениях, и пользователь мо жет добавлять правила, если он видит, что они необходимы. Примером такого правила может быть:

#Секция описания сервисов: На анализируемом узле найден netstat port 15 using protocol tcp => Service:Info Status:netstat

Данная проверка описывает правило, которое определяет наличие сервиса netstat на 15 ом TCP порту ана лизируемого узла. Более сложное следующее правило определяет наличие запущенного приложения SuperApp устаревшей версии по заголовку, возвращаемому на запрос, обращенный к портам 1234 или 1235.

#Пользовательская проверка: Приложение SuperApp 1.0 запущено на сканируемом хосте. (scanfor “SuperApp 1.0” on port 1234) || (scanfor “SuperApp 1.0 Ready” on port 1235) => VULp:Old Software:Super App Ancient:10003

Данная потенциальная уязвимость (VULp) относится к типу “устаревшее (потенциально уязвимое) программ ное обеспечение” (Old Software) и носит название Supper App Ancient, задаваемое пользователем. Число 10003 определяет уникальный номер записи в базе данных уязвимостей системы NetSonar (NSDB).

Механизм описания своих проверок и уязвимостей является очень полезной возможностью для администра торов, отслеживающих уязвимости, описанные в Bugtraq и иных списках рассылки.Эта возможность позво ляет быстро записать новое правило и использовать его в своей сети. Однако можно заметить, что язык, ис пользуемый в системе NetSonar и описывающий эти правила, достаточно элементарен и может помочь толь ко в самых простых случаях. В сложных ситуациях, когда проверку нельзя записать одним правилом, необхо димо использовать более сложные сценарии, которые достигаются применением языков Perl, Tcl и C.

Необходимо заметить, что хотя данная возможность и является полезной, ее эффективность достаточно эфе мерна. В своей практической деятельности мне не приходилось встречаться с организациями, которые могли бы себе позволить содержать целый штат или одного сотрудника, занимающихся исследованиями в области новых проверок и уязвимостей (я не беру в расчет силовые ведомства и иные организации, работающие в области защиты информации). Как правило, человек, отвечающий за обеспечение безопасности, не облада ет глубокими познаниями в программировании. Кроме того, помимо анализа защищенности на нем “висит” еще много других задач (контроль пользователей, установка прав доступа и т.д.), и он просто не имеет вре мени для такой творческой работы, как описание новых проверок.

3. Сканеры безопасности: выбор, порядок использования

На сегодняшний день известно более 50 средств анализа защищенности. Сказать, что какое то из них явля ется наилучшим, нельзя. Каждое из этих средств имеет свои достоинства и свои недостатки. Одни предназ начены только для одной операционной системы (как правило UNIX), другие требуют очень глубоких знаний архитектуры сети и ОС (например, SATAN), третьи предназначены для тестирования только одной из уязвимо стей сети (например, Crack). Поэтому прежде чем покупать средство анализа защищенности, необходимо тщательно проанализировать особенности используемого программного и аппаратного обеспечения собствен ной корпоративной сети и исходя из этого производить выбор.

По мнению специалистов, в России наиболее часто применяемыми в корпоративных сетях операционными си стемами являются UNIX и Windows NT. Причем данные ОС могут использоваться в рамках одной сети. Кроме того, корпоративная сеть может включать рабочие станции DOS и Windows 95 и сервера, работающие под управлени ем ОС Novell Netware. Средство анализа защищенности должно поддерживать если не все из перечисленных ОС, то большую их часть. Этому требованию наиболее удовлетворяют системы, входящие в семейство SAFEsuite аме риканской компании Internet Security Systems, Inc. (http://www.iss.net), основанной одним из основателей ко ординационного центра CERT Кристофером Клаусом.

В семейство SAFEsuite входит 3 системы:

•система анализа IP сетей . Internet Scanner;

•система анализа и изменения настроек UNIX систем . System Security Scanner;

•система оперативного обнаружения и реагирования на атаки RealSecure (рассмотрена выше).

Internet Scanner

Система Internet Scanner предназначена для обнаружения и слежения за появлением в корпоративной сети из вестных на сегодняшний день уязвимостей в существующих ОС и прикладных программах. Текущая версия (5.0) позволяет обнаруживать более 150 известных уязвимостей в Web серверах, межсетевых экранах (Firewall), мар шрутизаторах (CISCO), ОС UNIX (HP UX, SunOS, Solaris, Linux, AIX), Windows NT и Windows 95. Система Internet Scanner также позволяет тестировать операционные системы, на которые установлена поддержка стека прото колов TCP/IP, например, Windows for Workgroups, OS/2.

К числу уязвимостей, которые анализирует Internet Scanner, относятся: сервисы Web сервера и ОС (RPC, NFS, Sendmail, FTP, CGI и т.д.), сервисы, доступные через межсетевой экран, правила фильтрации, установленные по умолчанию пароли распространенных маршрутизаторов, слабые пароли, и многие другие.

Система Internet Scanner состоит из следующих компонентов:

49.8

Инструментальный анализ риска. Средства аудита (сканеры безопасности)

•Web Security Scanner;

•Firewall Scanner;

•Intranet Scanner

и представляет собой набор тестов уязвимостей различных ОС и прикладных программ.

Процесс анализа очень прост и заключается в выполнении всего 4 х операций:

1.выбор степени анализа защищенности (по шаблонам);

2.выбор сканируемых узлов сети;

3.собственно сам процесс сканирования узлов сети;

4.генерация отчета.

Администратор может использовать либо один из трех устанавливаемых изначально шаблонов, определяю щих степень детализации сканирования (Heavy, Medium, Light), либо создавать свои собственные шаблоны. Все используемые шаблоны можно сохранять для дальнейшего применения.

Отчеты представляются в текстовом или HTML формате и могут содержать:

•список найденных уязвимостей с их описанием и оценкой степени риска;

•перечень используемых сервисов и служб архитектуры TCP/IP на каждом узле сети;

•рекомендации по устранению найденных уязвимостей (описание действий, которые надо произвести для

ликвидации уязвимостей). Кроме того, для большинства уязвимостей даются ссылки на сервера в Internet, содержащие исправленные версии ПО, patch.и, hotfix.ы и т.д.

Версии системы от Internet Scanner 5.0, позволяют включать в создаваемые отчеты графику (диаграммы, рисунки и т.д.).

При генерации отчетов можно использовать возможность сравнения нескольких состояний сети, проверки которых проводились в разное время.

Весь процесс сканирования одной станции (при максимальной степени детализации): от запуска Internet Scanner до момента выдачи отчета занимает, примерно, 8 10 минут. Необходимо заметить, что данная система может быть запущена только администратором системы или пользователем, имеющим администраторские права. Пользователь, не имеющий таких прав, не сможет воспользоваться Internet Scanner.

Начиная с пятой версии Internet Scanner, администратор сможет сам пополнять базу данных уязвимостей.

System Security Scanner

Система System Security Scanner предназначена для проведения анализа защищенности UNIX узлов корпо ративной сети и управления их настройками в соответствии с политикой безопасности, принятой в органи зации.

Система System Security Scanner состоит из двух основных подсистем:

•Подсистемы анализа. Эта подсистема обеспечивает проверку настроек ОС UNIX на компьютере, на кото ром установлена эта ОС и их хранение в специальной базе данных. Эта база данных содержит в себе также сведения об известных уязвимостях ОС UNIX, известных исправлениях (security patches) и извес тных масках хакерских программ (hacker patterns). Эта подсистема может быть одновременно запущена как на одном, так и на нескольких узлах сети;

•Подсистемы управления. Эта подсистема запускается на одном из компьютеров сети и позволяет управ

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

Вотличие от Internet Scanner система System Security Scanner позволяет не только анализировать настройки системы, но и корректировать их. System Security Scanner позволяет проверять права доступа к файлам, кон фигурацию системы, целостность файлов, систему паролей, информацию о пользователях и группах и другие характеристики.

Вближайшее время компания ISS планирует выпустить версию System Security Scanner для операционной системы Windows NT.

Обе системы обладают удобным графическим интерфейсом (GUI), который позволяет быстро сконфигуриро вать и настроить систему, и следить за процессом сканирования из единого места . рабочей станции админи стратора системы.

Сравнительный анализ средств контроля безопасности на базе протокола IP

(по материалам Network Computing)

«Cканеры безопасности» (security scanners), появившиеся в результате совершенствования таких средств, как SATAN и SSS ISS, анализируют данные о настройке вашей системы безопасности, а затем, используя собствен ный алгоритм проверки, определяют имеющиеся «дыры» в системе безопасности или недостатки ее конфи гурации.

Вданном обзоре приводятся испытания четырех таких сканеров: NetSonar Vulnerability Scanner фирмы Cisco Systems, Internet Scanner 5.0 фирмы Internet Security Systems (ISS), Netective Site 1.0 фирмы NETECT и Ballista Security Auditing System 2.4 фирмы Secure Networks.

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

49.9

Инструментальный анализ риска. Средства аудита (сканеры безопасности)

Продукт Netective единственный выполняет проверку программных кодов и обеспечивает эффективное об новление версий ПО. Кроме того, процедуры лицензирования Netective и Internet Scanner оказались весьма сложными и у большинства протестированных продуктов механизм формирования отчетов является недо статочно гибким. Если бы объединить интерфейс Internet Scanner с тщательностью проверки и гибкостью Ballista, а также с имеющимися возможностями Netective по принудительному обновлению программ с про веркой работоспособности системы и добавить к этому гибкость настройки генератора отчетов NetSonar, то это было бы просто здорово!

Лучшим может быть назван Interne. Он более аккуратен, чем другие сканеры. Данный продукт содержит наи более качественный и полный набор средств проверки для Windows NT, начиная от определения возможнос ти атаки типа «отказ в обслуживании» до проверки уязвимости режима администрирования системы. С его помощью также можно исключить использование очевидных паролей. При наличии в арсенале Internet Scanner ряда средств для проверки Unix систем, низкоуровневого IP тестирования, а также информации о «дырах» в системах VAX/VMS, он представляется достаточно хорошим и законченным продуктом.

Internet Scanner 6.0 фирмы ISS

Занимающаяся уже продолжительное время созданием средств обеспечения безопасности компания ISS при внесла свой многолетний опыт в новую разработку — «сканер безопасности». Данный программный инстру мент обеспечивает проведение самых разных проверок и предоставляет сетевому администратору деталь ные отчеты. Internet Scanner — наиболее тщательно разработанный продукт из тех, которые мы протестиро вали. Конкуренцию ему может составить только сканер Ballista производства Secure Networks. Тем не менее, как и другие продукты, Internet Scanner имеет недостатки, заключающиеся в неспособности обнаруживать некоторые «дыры» в защите сети и в медленной процедуре обновления ПО, осуществляемой вручную.

Internet Scanner может работать на сервере Windows NT, также поддерживает ОС AIX, HP UX, Linux и Solaris). По завершении инсталляции программа предлагает выбрать один из трех возможных вариантов сканирова ния: упрощенный, обычный и интенсивный.

Internet Scanner оказался единственным из испытывавшихся продуктов, который смог обнаружить извест ную «прореху» в программе NetWare Web Server 2.5. Используя некорректную CGI программу, злоумышлен ник мог получить доступ практически ко всем файлам системы, в частности к файлу AUTOEXEC. NCF, который обычно содержит пароль для команды RCONSOLE. И хотя Internet Scanner не до конца справился с другой проблемой, он все же во время испытаний привлек к ней внимание, выдав предупреждение общего характе ра «./../», чему причиной оказалась «дыра» в ПО Internet Information Server.

Подобно продукту Ballista, Internet Scanner осуществляет несколько процессов сканирования одновременно, что весьма позитивно отражается на общей производительности. В тестируемой нами сети программа проска нировала 20 узлов менее чем за 15 мин. Только в самом конце испытаний возникла проблема. Во время скани рования третьей по счету сети процесс «завис» на машине с ОС Windows NT. Даже после того, как тестирование других узлов было закончено, Internet Scanner все еще продолжал работу на этой машине.

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

Весьма примечателен во многих отношениях механизм генерации отчетов, имеющийся в Internet Scanner. Ис пользуя готовые формы, вы можете получить любой отчет — от иллюстрированных графиками сводок для руководства до подробных технических данных по каждому возможному месту взлома с рекомендациями по его устранению. Особенно удобен детальный технический отчет. Пытаясь решить проблему, связанную с уда ленным запросом учетных имен в операционной системе Windows NT, мы получили точные инструкции по изменению системного реестра и ссылки на статьи в MS Knowledge Base для доступа к дополнительной ин формации. К сожалению, механизм генерации отчетов тоже не лишен некоторых недостатков. Во время под готовки отчетов неудовлетворительно работала функция сортировки по IP адресам. Принятый компанией ISS график выпуска обновленных версий продукта (всего лишь несколько раз в году) тоже представляется недо статочно продуманным.

Ballista Security Auditing System фирмы Secure Networks

Тестирование продукта Ballista Security Auditing System выполнялось на аппаратной платформе Intel с ОС Windows NT и Linux. ПО Ballista предоставляет собой развитый комплекс средств для углубленной проверки сетевой бе зопасности с возможностью его адаптации к нуждам пользователя. Проводя обновление ПО каждые две неде ли, Ballista устраняет тем самым недостаток, присущий программе Internet Scanner.

Во время тестирования программа Ballista обнаружила, что в конфигурации Secure Shell (SSH) нескольких уз лов сети установлены доверительные отношения с удаленными хостами. В противоположность этому програм ма Internet Scanner полностью проигнорировала информацию о SSH. Если Secure Networks сумеет обеспечить в своем продукте большую функциональность механизма генерации отчетов, добавив к нему, например, рекомен дации по устранению проблем и ссылки на дополнительные источники информации, а также придаст больше гибкости процедуре сканирования, тогда можно будет говорить о нем как о хорошем конкуренте Internet Scanner. Ballista обнаруживает большинство «дыр», но не предлагает решений по их устранению, вынуждая вас само стоятельно искать пути их ликвидации.

49.10

Инструментальный анализ риска. Средства аудита (сканеры безопасности)

Ballista предлагает вам несколько весьма интересных функций, включая активный подбор паролей. Эта фун кция наверняка придется по душе опытным пользователям Unix систем, которых не устраивают функциональ ные возможности системы парольной защиты Windows NT.

Ballista располагает широкими возможностями для индивидуальной настройки ПО. С помощью инструмента САРЕ было добавлено несколько своих сценариев в ходе тестирования на предмет предполагаемых атак типа «отказ в обслуживании».

Ballista поддерживает самые разные платформы, включая все, какие только есть, реализации Unix на ос нове Intel.

Следует все же отметить основные недостатки программы Ballista. Не предоставляя вам простых способов сортировки данных, Ballista может вызвать у вас чувство обреченности.

Еще одним недостатком Ballista является избыточность предупреждений об угрозах с небольшой степенью вероятности. Особенно удивителен случай, когда Internet Scanner выдал 9 предупреждающих сообщений об одном из Unix узлов, a Ballista — целых 19! Одно из предупреждений, выданных Ballista, касалось информа ции, распространяемой через Telnet. Причина появления данного предупреждения оказалась в следующем. Подозрительный узел выдавал каждому пытавшемуся обратиться к нему следующую строчку: «Всем незаре гистрированным пользователям устроим “темную”!». Получив от Ballista такого рода «сюрпризы» и не имея дополнительной информации, слабо подготовленные в вопросах безопасности системные администраторы долго чесали бы затылки, прежде чем поняли, что это просто шалость.

И еще: вопреки тому, что программа обеспечивает значительно более детализированную проверку серверов DNS по сравнению с другими продуктами, она все же «не заметила» некоторые серьезные «дыры», включая возможность атаки типа «Red Button».

Рис. 1. Internet Scanner обеспечивает генерирование детальных отчетов в различных форматах, включая HTML

NetSonar Vulnerability Scanner фирмы Cisco Systems

Первый официальный релиз программы NetSonar вошел в номенклатуру продукции фирмы Cisco после при обретения ею компании WheelGroup. В настоящее время NetSonar поддерживает только ОС Solaris (как для Intel, так и SPARC). Продукт обеспечивает широкие возможности в части сканирования сети, генерации отче тов и настройки конфигурации. Тем не менее его отчеты недостаточно детально проработаны. Общее впечат ление от NetSonar хорошее, но в какой либо отдельной области он не выделяется. Во время тестирования NetSonar обнаружил большинство «дыр», но его производительность была заметно ниже, чем у остальных продуктов. Требования к объему памяти компьютера — минимум 64 Мбайт ОЗУ в сочетании с размером фай ла подкачки в 384 Мбайт — явились первым признаком того, что в продукте имеются какие то недоработки. Отставив в стороне вопрос о производительности, отметим, что NetSonar предлагает хороший комплекс про цедур проверки безопасности систем и выполняет углубленный поиск «дыр». Во время тестирования про грамма предложила нам задать расписание множественных сеансов сканирования. В дополнение к этому NetSonar обеспечивает очень гибкое формирование отчетов с помощью схем, графиков и обобщенного пред ставления полученных данных.

Аналогично Internet Scanner данная программа может формировать отчеты для специалистов разного уровня — от руководителей до инженеров. Продукт NetSonar может занять прочные позиции в своем секторе рынка, если будет снабжен более подробными рекомендациями. В отличие от Internet Scanner, который всегда отсылает к ис

49.11

Инструментальный анализ риска. Средства аудита (сканеры безопасности)

точникам с детальным описанием проблем и их решений, большинство сообщений NetSonar об обнаруженных ошиб ках представляли собой несколько рекомендаций с изредка встречающимися ссылками на другие источники. Хотя недостаток детализации вызвал у нас чувство неудовлетворения, мы отдали должное гибкой политике лицензирования NetSonar. Для тестирования была предоставлена лицензия для класса С, позволяющая ра ботать с любым количеством адресов, начиная с 255. Для администраторов сетей среднего класса с фикси рованной конфигурацией это может и не иметь значения. Но независимые консультанты наверняка такую возможность одобрят. В отличие от Cisco фирма ISS предлагает посетить ее Web узел, и после указания се рийного номера продукта вы должны будете выбрать фиксированный диапазон IP адресов (которые Internet Scanner все равно воспринимает не полностью), загрузить соответствующий текстовый ключ, а затем ввести его в вашу программу. Что же касается продукта Ballista, то в нем для аналогичных целей используется про цедура интерактивной генерации ключа.

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

Netective Site фирмы NETECT

Явно выделяясь среди протестированных программ скоростью своей работы, продукт Netective Site произ водства фирмы NETECT все же выглядит «недорослем». Созданный на базе очень мощного алгоритма, он тем не менее не обеспечивает той тщательности проверки, какая характерна для Ballista и Internet Scanner. Во время лабораторных испытаний эта программа не смогла обнаружить значительное количество серьезных «дыр» в защите сетей.

Для проверки серверов Solaris был применен Netective Site на базе процессоров SPARC. Подобно NetSonar, Netective Site проверяет все ОС, но работает только на компьютерах фирмы Sun Microsystems. Компания NETECT почти все внимание сконцентрировала на обновлении версий и на функции проверки программных кодов. Очевидно, фирма разработчик должна приложить больше усилий в области поддержки базы данных для про цедур проверки, иначе продукт будет неизбежно проигрывать по основным направлениям тестирования. Во время испытаний Netective Site полностью игнорировал «дыры» в службах DNS и «не обращал никакого вни мания» на проблемы, связанные с нижним уровнем IP, уязвимыми местами маршрутизации, равно как и с выполнением команды admin ОС Solaris, и на другие аналогичные критические места в области безопаснос ти. Отметим также, что программа не могла верно определять типы серверов.

Netective Site предоставляет ссылки для обращения за дополнительной информацией, хотя здесь не обошлось без курьеза. С одной стороны, когда мы разбирались с поступавшими сообщениями Netective Site во время проверки им сервера Samba, то обнаружили ссылку на прекрасный Web ресурс, посвященный проблемам SMB/ CIFS. Наличие такой функции у всех программ можно было бы только приветствовать. С другой стороны, Netective Site принял маршрутизатор Cisco 3000 за некий «гибрид» Unix и Windows NT, указав при этом, что служба Samba запущена на нем одновременно с Netscape Web Server. Эта досадная ошибка вообще не имеет смысла, поскольку IOS фирмы Cisco даже и не предполагает самой возможности такой работы.

Netective Site выгодно отличается от других продуктов своими функциями в части обновления версий ПО. Одно из самых существенных нареканий к большинству программ заключалось в том, что их обновление осуществля ется очень редко. Компания NETECT учла этот недостаток и исправила его в своем продукте. Используя простую почтовую программу SMTP, Netective Site получает необходимое обновление с Web узла компании. Следует от метить, что NETECT — единственный разработчик, обеспечивший такую возможность. Во время испытаний ав томатически был получен с Web узла новый файл с дополнениями и программа самостоятельно производила обновление. Данный процесс требует использования цифровой подписи, благодаря чему можно своевременно получить полный, безопасный и качественный пакет. Нельзя не отметить и хороший дизайн интерфейса. Коро че — вся процедура обновления вызывает полное одобрение.

Функция контроля целостности программных кодов Netective Site значительно превосходит по своей действен ности такие же функции, имеющиеся во всех остальных программах. Если вы знакомы с пакетом программ Unix Trip wire, вы наверняка согласитесь с нашим мнением. Взломщики довольно часто заменяют основные файлы и программы их модифицированными версиями, открывающими доступ ко всей вашей системе. Избавиться от по следствий таких атак на важнейшие программы в большинстве случаев можно только путем полной переуста новки системы. Чтобы бороться с подобными вторжениями, встроенная утилита Netective Scanner «опрашива ет» все файлы и проверяет их подлинность на уровне двоичного кода. Благодаря такому алгоритму почти не возможно обмануть сканер, внося изменения в файлы.

Это было проверено на сервере Netra фирмы Sun, работающем под управлением операционной системы Solaris 2.6. Используя процедуру обновления Netective и имеющийся дистрибутив, исследователи получили набор под писей для проверки подлинности программ. Затем они заменили программу ping на ее модифицированную вер сию, имеющую скрытую функцию, которая предоставляет полный доступ к ресурсам машины. Вновь запустив Netective, исследователи получили предупреждение и рекомендацию проверить подозрительную программу. Netective оказался единственным продуктом, обеспечивающим такую высококачественную проверку. К со жалению, он работает только на платформе Solaris. В следующей версии продукта компания NETECT плани рует дополнить вышеуказанную процедуру программой агентом, которая будет направлять информацию глав ной программе — сканеру Netective.

49.12

Инструментальный анализ риска. Средства аудита (сканеры безопасности)

Конфигурация тестовой среды

Тестовая среда состояла из набора следующих устройств и платформ: маршрутизаторы, концентраторы и комму таторы фирм Cisco Systems и Bay Networks; ОС AIX, Linux, NetWare, Solaris и Windows NT. Использовались не только различные виды ОС, но и их различные версии — чередование ОС IOS 9.0 и IOS 11.2, AIX 4.1 и AIX 3.1, а также NetWare 3.12 и NetWare 4.1. Кроме машин, выполняющих обычные функции, использовались машины с всевозмож ными «дырами» в их системе защиты. Часть машин работала под управлением обновленных версий ОС, в то время как другая часть управлялась устаревшими их версиями. Таким образом, была образована причудливая смесь стан дартных и «доморощенных» сетевых компонентов, включающая случайный набор всех известных «дыр».

Результаты испытаний сведены в таблицы 1 и 2.

Таблица 1.

Средства контроля безопасности: результаты тестирования

Примечание. Оценки выставлялись по пятибалльной системе

Таблица 2.

Характеристики средств контроля безопасности

Примечание:

l — есть, m — нет, Т/с — требует согласования с продавцом. * — Свыше 2000 устройств.

49.13

Инструментальный анализ риска. Средства аудита (сканеры безопасности)

Информация о поставщиках

Internet Scanner 5.0

Фирма: Internet Security Systems http://www. iss. net

Netective Site 1.0

Фирма: NETECT http://www. netect.com

Ballista Security Auditing System 2.4 Фирма: Secure Networks

http://www. securenetworks. corn

NetSonar Vulnerability Scanner and Network Mapping System 1.0

Фирма: Cisco Systems

Заключение

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

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

49.14