Различные типы окружений firewall’а

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

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

Без наличия политики безопасности администраторы работают "втемную". Firewall’ы могут быть сложными и трудными с точки зрения управления, и инциденты, связанные с безопасностью, могут возникать ежедневно. Без политики, определяющей, кроме всего прочего, управление firewall’ом, он сам может создавать проблемы, связанные с безопасностью.

Политика firewall’а

Политика firewall’а определяет, как firewall должен обрабатывать трафик различных приложений, таких как web, e-mail или telnet. Политика также должна описывать, как сам firewall управляется и модифицируется.

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

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

Должны выполняться следующие шаги при создании политики firewall’а:

• Определение необходимых сетевых приложений.
• Определение уязвимостей, связанных с приложениями.
• Анализ соотношения цены и качества для методов, используемых в обеспечении безопасности приложений.
• Определение трафика приложений с учетом способов защиты.
• Создание правил firewall’ов, основанных на трафике приложений.

Реализация набора правил firewall’а

Большинство реализаций firewall’ов используют наборы правил в качестве механизма для реализации управления трафиком. Возможная совокупность этих правил определяет реальную функциональность firewall’а. В зависимости от архитектуры реализации firewall’а набор правил может включать в себя различные блоки информации. Тем не менее все они содержат как минимум следующие поля:

• адрес источника пакета, например, адрес 3 уровня компьютерной системы или устройства, откуда получен сетевой пакет (IP-адрес);
• адрес назначения пакета, например, адрес 3-го уровня компьютерной системы или устройства, куда пакет должен быть доставлен;
• тип трафика, т.е. конкретный сетевой протокол, используемый для взаимодействия систем или устройств источника или получателя, – например, IP на 3-м уровне или ТСР и UDP на 4-м уровне;
• возможно, некоторые характеристики коммуникационных сессий 4-го уровня – протокол, такой, как ТСР, и порты источника и назначения (например, ТСР:80 для порта назначения, принадлежащего web-серверу, ТСР:1320 для порта источника, получающего доступ к серверу);
• иногда информация, относящаяся к интерфейсу роутера, с которого пришел пакет, и к интерфейсу роутера, для которого пакет предназначен, – используется для роутеров с тремя и более сетевыми интерфейсами;
• действие, такое как Deny или Block пакета, или Drop пакета, когда пакет отбрасывается и отправителю пакета не возвращается ответ, содержащий информацию о том, что ему запрещена пересылка; либо Allow, Pass или Accept, когда пакет пропускается через firewall.

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

Набор правил может быть создан после определения трафика приложений. В зависимости от firewall’а это может выполняться с использованием интерфейса в стиле web; в случае пакетных фильтров набор обычно является текстовым файлом. Набор должен быть создан как можно более конкретно в соответствии с трафиком, который он контролирует. Он должен быть как можно более простым, чтобы случайно не появилось "дырок" в firewall’е, которые могут допустить прохождение неавторизованного или нежелательного трафика через firewall.

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

Набор правил firewall’а должен всегда блокировать следующие типы трафика:

• входящий трафик от неаутентифицированного источника с адресом назначения самого firewall’а. Данный тип пакета обычно является некоторым типом зондирования или атакой, направленной на сам firewall. Одним общим исключением из этого правила может служить случай, когда firewall обеспечивает доставку входящего e-mail (SMTP на порт 25). Тогда firewall должен разрешить входящие соединения к самому себе, но только на порт 25;
• входящий трафик из внешней сети с адресом источника, указывающим, что пакет получен из сети, расположенной позади firewall’а. Данный тип пакета обычно представляет собой некоторый тип попыток spoofing’а (подделки);
• входящий трафик, содержащий ICMP-трафик. Так как ICMP может использоваться для определения расположенных позади firewall’а сетей, ICMP не должен передаваться внутрь из Интернета или из любой недоверяемой внешней сети;
• входящий или исходящий трафик от системы, использующей адрес источника из множества диапазонов адресов, которые в соответствии с RFC 1918 зарезервированы для частных сетей:

  С 10.0.0.0 до 10.255.255.255 (Класс "А" или "/8" в CIDR-нотации);

  С 172.16.0.0 до 172.31.255.255 (Класс "В" или "/12" в CIDR-нотации);

  С 192.168.0.0 до 192.168.255.255 (Класс "С" или "/16" в CIDR-нотации).

Входящий трафик с этими адресами источника обычно указывает на начало DoS-атаки, имеющий TCP SYN флаг:

• входящий трафик от неаутентифицированного источника, содержащий SNMP- трафик. Эти пакеты могут указывать, что атакующий прощупывает сеть. Возможны определенные причины, по которым организация может разрешить входящий SNMP-трафик, но в большинстве случаев он должен быть блокирован;
• входящий или исходящий сетевой трафик, содержащий адрес источника или назначения 127.0.0.1 (localhost). Такой трафик обычно является некоторым типом атаки на сам firewall;
• входящий или исходящий сетевой трафик, содержащий адрес источника или назначения 0.0.0.0. Некоторые ОС интерпретируют данный адрес либо как localhost, либо как broadcast-адрес, в любом случае эти пакеты могут использоваться для атаки;
• входящий или исходящий сетевой трафик, содержащий directed broadcast адреса. Directed broadcast часто используется для начала broadcast’ового распространения атаки, такой как SMURF. Directed broadcast позволяет, чтобы один компьютер посылал broadcast’овое сообщение с подделанным адресом источника. Любая система, которая отвечает на directed broadcast, посылает свой ответ системе, указанной в качестве источника, а не самому источнику. Эти пакеты могут быть использованы для создания "шторма" сетевого трафика, например, для блокирования некоторых сайтов.

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

Большинство firewall’ов поддерживают несколько опций для создания логов. Эти опции имеют широкий диапазон, от создания простых записей логов до оповещения администратора о наступлении некоторого события. В зависимости от способа оповещения данное действие может реализовываться различными способами: от посылки уведомления по e-mail до телефонного сообщения соответствующему персоналу.

Тестирование политики firewall’а

Политика firewall’а должна периодически проверяться, по крайней мере, ежеквартально.

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

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

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

Возможные подходы к эксплуатации firewall’а

При эксплуатации и определении политики firewall’а следует решить, использовать ли firewall в виде отдельного аппаратно-программного средства (appliance) или в составе ОС. Хотя данное решение в большей степени определяется требованиями организации, должны быть рассмотрены следующие аспекты:

• В общем случае, аппаратно-программные firewall’ы являются более безопасными, чем те, которые реализованы в ОС. Аппаратно-программные firewall’ы не имеют уязвимостей, связанных с лежащей в их основе ОС. Они обычно реализуют технологию ASIC (Application-Specific Integrated Circuit); при этом ПО firewall’ов реализовано в виде firmware. Эти firewall’ы обычно более производительные, чем те, что реализованы в ОС.
• Преимуществом реализации firewall’ов в ОС является их масштабируемость. Если окружение потребует большей производительности, организация может купить более мощную систему, на которой будет выполняться ПО firewall’а. Большинство аппаратно-программных firewall’ов не имеют такой степени гибкости и масштабируемости.
• Самым большим недостатком реализации firewall’ов в ОС является потенциальное наличие уязвимостей в этой ОС, которые могут нарушить безопасность самого firewall’а. В большинстве случаев, когда коммерческие firewall’ы взламываются, этот взлом происходит из-за уязвимостей лежащей в их основе ОС.

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

Сопровождение firewall’а и управление firewall’ом

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

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

В обоих случаях следует иметь гарантии, что для всего сетевого трафика, предназначенного для системы управления firewall’ом, выполняются требования безопасности. Для интерфейсов, основанных на web, данная безопасность реализуется использованием неанонимного SSL с последующей аутентификацией пользователя по ID и паролю. Для собственных (не-web) интерфейсов обычно реализуется тот или иной способ шифрования транспорта. То, что все функции управления firewall’ом должны выполняться по безопасным каналам с использованием строгой аутентификации и шифрования, должно быть явно указано в политике.

Физическая безопасность окружения firewall’а

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

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

Наконец, firewall должен быть защищен от различных стихийных бедствий.