Политика брандмауэра

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

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

4.1.1 Шаги при создании политики сетевого доступа

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

Как уже объяснялось в главе 2.4.1, типовыми политиками проектирования брандмауэра являются запрет всех сервисов, кроме тех, что явно разрешены, или разрешение на доступ ко всем сервисам, кроме тех, что явно запрещены. Первый тип более безопасен и поэтому предпочтителен, но он также более строг, в результате чего при нем допускается работа меньшего числа сервисов. Глава 3 содержит несколько примеров брандмауэров, и в ней наглядно показано, что некоторые типы брандмауэров могут реализовывать оба вида политики управления доступом, в то время как брандмауэр на основе шлюза с двумя интерфейсами предназначен для реализации политики "все, что не разрешено - запрещено". Кроме того, эти примеры показывают, что системы, требующие обеспечения доступа к сервисам, не пропускаемым брандмауэром, могут быть размещены в изолированных подсетях отдельно от других внутренних систем. Клчевым моментом здесь является то, что в зависимости от требований обеспечения безопасности и гибкости, некоторые типы брандмауэров более предпочтительны, чем другие. Этот факт подчеркивает важность правильного выбора политики до начал создания брандмауэра; другой порядок действий нецелесообразен.

Для того, чтобы правильно разработать концептуальную политику брандмауэра, а затем систему брандмауэра, которая реализует эту политику, NIST рекмоендует, чтобы сначала был разработан самы безопасный вариант политики - то есть запретить все сервисы, кроме тех, что явно разрешены. Разработчики политики должны разбираться в следующих вопросах и задокументировать их:

Ответы на эти вопросы просты, но отвечать на них скорее всего придется несколько раз. Например, организация может хотеть использовать NFS между двумя удаленными сетями, но политика "запрещать все, что не разрешено" может запрещать доступ к NFS (как это объясняется в пункте 2.4.1). Если риск, связанный с NFS, приемлем для организации, то потребуется переработка концептуальной политики брандмауэра на менее строгую - разрешение всех сервисов, кроме тех, которые явно запрщены, и разрешение пропускать NFS через брандмауэр к внутренним системам. Или же может потребоваться приобретение брандмауэра, который может разместить системы, которым требуется NFS, в изолированной подсети, позволяя таким образом оставить политику "запрещать все, что не разрешено". Или риск использования NFS может оказаться слишком большим; и NFS будет исключен из списка сервисов, которые разрешено использовать удаленным системам.

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

4.1.2 Гибкость политики

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

4.1.3 Политика усиленной аутентификации удаленных пользователей

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

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

4.1.4 Политика доступа через модемы

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

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

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

4.1.5 Удаленные соединения с сетью организации

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

В части 3 имеется несколько примеров размещения средств организации доступа по модемам таким образом, что соединения проходят через брандмауэр. Такое же размещение может быть использовано и для протоколов SLIP и PPP, но их следует заранее описать а политике. Обычно политика очень строго регламентирует соединения подобного рода.

4.1.6 Политика для информационного сервера

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

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

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

Знаете ли Вы, что класс, Class - Класс в программировании - это множество объектов, которые обладают одинаковой структурой, поведением и отношением с объектами из других классов.