30.09.2003

Теория и практика файрволинга локальной сети, Часть первая. Теория.

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

По материалам из моей головы

«ДМЗ – это единственный контролируемый администратором сегмент корпоративной сети»

«Я не верю в практическую ценность систем обнаружения атак»

Отцы информационной безопасности.


В эпиграф вынесены фразы специалистов в области информационной безопасности, чьи имена слишком известны, что бы упоминать их в этой статье. Первая из них не вызывает особых нареканий, поскольку действительно, трафик небольшого количества серверов, зажатых между двумя межсетевыми экранами (МЭ) можно довольно жестко регламентировать с помощью правил фильтрации. Если в ДМЗ находится, предположим, почтовый сервер то мы разрешаем взаимодействовать из внутренней сети по тем почтовым протоколам, которые необходимы для работы пользователей (SMTP, IMAP) и запрещаем все протоколы. Так же можно и ограничить взаимодействие сервера с внешней средой только протоколом SMTP. 

Можно ли реализовать подобный уровень безопасности, в локальной сети? Жестко регламентировать тип трафика, разрешить взаимодействие клиентов с серверами только по необходимым протоколам и блокировать весь остальной трафик. 

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

Данный подход, соответствующий концепции Defence from depth to inside позволяет довольно жестко разграничить доступ пользователей к сетевым службам и значительно увеличить защищенность сети. Фильтруя весь трафик с помощью «распределенного» межсетевого экрана мы защищаемся от атак через неиспользуемые и неверно сконфигурированные сетевые службы, контролируем размножение сетевых червей и блокируем несанкционированную сетевую активность пользователей (установку сетевых служб, работу с этими службами и т.д.).

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

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

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

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

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

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

Основная проблема в реализации данного подхода может возникнуть при использовании приложений открывающих несколько независимых соединений и использующих динамическую привязку служб к портам. Типичные примеры – FTP, и RPC. И если проблема с FTP довольно просто решается, (я бы вообще решил её путем отказа от использования данного сервиса), то достаточно мощного процессора RPC я не встречал ни в одной системе обнаружения атак (даже в Real Secure, даже в ней). Однако я думаю, это дело времени.

Другая проблема возникает с трафиком приложений использующих протоколы отличные от TCP. Троянские программы, программы обмена сообщениями и другой полезный в производственной среде софт, вполне может использовать протоколы UDP или ICMP для клиент/серверного обмена. 

Здесь нам остается только одно – включить журналирование данного типа трафика на NIDS, читать журналы и шлепать по рукам не в меру ретивых пользователей.
Но естественно, использование NIDS для фильтрации трафика не отменяет необходимость использования персональных межсетевых экранов (особенно если это RealSecure Server Sensor, особенно если он), а является дополнительным методом контроля и обнаружения сбоев в работе «распределенного» межсетевого экрана вашей локальной сети.


10x 4 U @tenzen. asu4ka. 
PS. TSS :-P

или введите имя

CAPTCHA