Гибридные технологии firewall’а
Недавние разработки в области сетевой инфраструктуры и информационной безопасности привели к стиранию границ между различными типами firewall’ов, которые обсуждались выше. Как результат, программные продукты firewall’ов соединяют функциональности нескольких различных типов firewall’ов. Например, многие производители прикладных прокси реализуют базовую функциональность пакетных фильтров.
Также многие разработчики пакетных фильтров или stateful inspection пакетных фильтров реализуют базовую функциональность прикладных прокси для ликвидации слабых мест, связанных с этими типами firewall’ов. В большинстве случаев производители реализуют прикладные прокси для улучшения создания логов и аутентификации пользователя.
После того как все основные производители будут использовать в своих продуктах в том или ином виде гибридные технологии, не всегда просто будет решить, какой продукт наиболее подходит для данного приложения или инфраструктуры предприятия. Гибридные свойства платформ firewall’ов делают особенно важной фазу оценки firewall’а. При выборе продукта важнее оценить поддерживаемое количество возможностей, чем формально смотреть тип firewall’а.
Host-based firewall’ы
Пакетные фильтры реализованы в некоторых ОС, таких как Unix/Linux; в частности, они могут использоваться только для обеспечения безопасности хоста, на котором они функционируют. Это может быть полезно при совместном функционировании с различными серверами; например, внутренний web-сервер может выполняться на системе, на которой функционирует host-based firewall.
Преимущества host-based firewall’а:
Приложение сервера защищено лучше, чем если бы оно выполнялось на ОС, не имеющей host-based firewall’а: внутренние серверы должны быть сами по себе защищены, и не следует предполагать, что они не могут быть атакованы только потому, что они расположены позади основного firewall’а.Выполнение firewall’а на отдельном хосте не является необходимым условием для обеспечения безопасности сервера: host-based firewall достаточно хорошо выполняет функции обеспечения безопасности.ПО, реализующее host-based firewall, обычно предоставляет возможность управления доступом для ограничения трафика к серверам и от серверов, выполняющихся на том же хосте, и обычно существуют определенные возможности создания логов. Хотя host-based firewall’ы менее предпочтительны в случае большого трафика и в окружениях с высокими требованиями к безопасности, для внутренних сетей небольших офисов они обеспечивают адекватную безопасность при меньшей цене.
Недостаток host-based firewall’а:
Каждый такой firewall должен администрироваться самостоятельно, и после определенного количества серверов с host-based firewall’ами легче и дешевле просто разместить все серверы позади выделенного firewall’а.
Классификация firewall’ов
Firewall’ы являются устройствами или системами, которые управляют потоком сетевого трафика между сетями с различными требованиями к безопасности. В большинстве современных приложений firewall’ы и их окружения обсуждаются в контексте соединений в Интернете и, следовательно, использования стека протоколов ТСР/IP. Однако firewall’ы применяются и в сетевых окружениях, которые не требуют обязательного подключения к Интернету. Например, многие корпоративные сети предприятия ставят firewall’ы для ограничения соединений из и во внутренние сети, обрабатывающие информацию разного уровня чувствительности, такую как бухгалтерская информация или информация о заказчиках. Ставя firewall’ы для контроля соединений с этими областями, организация может предотвратить неавторизованный доступ к соответствующим системам и ресурсам внутри чувствительных областей. Тем самым, использование firewall’а обеспечивает дополнительный уровень безопасности, который иначе не может быть достигнут.
В настоящее время существует несколько типов firewall’ов. Одним из способов сравнения их возможностей является перечисление уровней модели OSI, которые данный тип firewall’а может анализировать. Модель OSI является абстракцией сетевого взаимодействия между компьютерными системами и сетевыми устройствами. Рассмотрим только уровни модели OSI, относящиеся к firewall’ам.
Стек протоколов модели OSI определяется следующим образом:
| Уровень 7 | Application |
| Уровень 6 | Presentation |
| Уровень 5 | Session |
| Уровень 4 | Transport |
| Уровень 3 | Network |
| Уровень 2 | Data Link |
| Уровень 1 | Physical |
Уровень 1 представляет собой реальную аппаратуру физического соединения и среду, такую как Ethernet. Уровень 2 — уровень, на котором сетевой трафик передается по локальной сети (LAN). Он также является первым уровнем, обладающим возможностью адресации, с помощью которой можно идентифицировать отдельную машину. Адреса назначаются на сетевые интерфейсы и называются МАС (Media Access Control) адресами. Ethernet-адрес, принадлежащий Ethernet-карте, является примером МАС-адреса уровня 2.
Уровень 3 является уровнем, отвечающим за доставку сетевого трафика по WAN. В Интернете адреса уровня 3 называются IP-адресами; адреса обычно являются уникальными, но при определенных обстоятельствах, например, при трансляции сетевых адресов (NAT) возможны ситуации, когда различные физические системы имеют один и тот же IP-адрес уровня 3. Уровень 4 идентифицирует конкретное сетевое приложение и коммуникационную сессию в дополнение к сетевым адресам; система может иметь большое число сессий уровня 4 с другими ОС. Терминология, связанная с семейством протоколов ТСР/IP, включает понятие портов, которые могут рассматриваться как конечные точки сессий: номер порта источника определяет коммуникационную сессию на исходной системе; номер порта назначения определяет коммуникационную сессию системы назначения. Более высокие уровни (5, 6 и 7) представляют приложения и системы конечного пользователя.
Стек протоколов TCP/IP соотносится с уровнями модели OSI следующим образом:
| Уровень 7 | Application | Почтовые клиенты, web-браузеры |
| Уровень 4 | Transport | ТСР-сессии |
| Уровень 3 | Network | IP-адресация |
| Уровень 2 | Data Link | Ethernet-адресация |
Независимо от архитектуры firewall может иметь дополнительные сервисы. Эти сервисы включают трансляцию сетевых адресов (NAT), поддержку протокола динамической конфигурации хоста (DHCP) и функции шифрования, тем самым являясь конечной точкой VPN-шлюза, и фильтрацию на уровне содержимого приложения.
Многие современные firewall’ы могут функционировать как VPN-шлюзы. Таким образом, организация может посылать незашифрованный сетевой трафик от системы, расположенной позади firewall’а, к удаленной системе, расположенной позади корпоративного VPN-шлюза; firewall зашифрует трафик и перенаправит его на удаленный VPN-шлюз, который расшифрует его и передаст целевой системе. Большинство наиболее популярных firewall’ов сегодня совмещают эти функциональности.
Многие firewall’ы также включают различные технологии фильтрации активного содержимого. Данный механизм отличается от обычной функции firewall’а тем, что firewall теперь также имеет возможность фильтровать реальные прикладные данные на уровне 7, которые проходят через него. Например, данный механизм может быть использован для сканирования на предмет наличия вирусов в файлах, присоединенных к почтовому сообщению. Он также может применяться для фильтрации наиболее опасных технологий активного содержимого в web, таких как Java, JavaScript и ActiveX. Или он может быть использован для фильтрации содержимого или ключевых слов с целью ограничения доступа к неподходящим сайтам или доменам. Тем не менее компонент фильтрации, встроенный в firewall, не должен рассматриваться как единственно возможный механизм фильтрации содержимого; возможно применение аналогичных фильтров при использовании сжатия, шифрования или других технологий.
Пакетные фильтры
Самый основной, базовый, первоначально разработанный тип firewall’а называется пакетным фильтром. Пакетные фильтры в основном являются частью устройств роутинга, которые могут управлять доступом на уровне системных адресов и коммуникационных сессий. Функциональность управления доступом обеспечивается с помощью множества директив, называемых ruleset или rules (правила).
Вначале пакетные фильтры функционировали на уровне 3 (Network) модели OSI. Данная функциональность разработана для обеспечения управления сетевым доступом, основываясь на нескольких блоках информации, содержащихся в сетевом пакете. В настоящее время все пакетные фильтры также анализируют и уровень 4 (Transport).
Пакетные фильтры анализируют следующую информацию, содержащуюся в заголовках пакетов 3-го и 4-го уровней:
Адрес источника пакета, например, адрес уровня 3 системы или устройства, откуда получен исходный сетевой пакет (IP-адрес, такой как 192.168.1.1).Адрес назначения пакета, например, адрес уровня 3 пакета, который он пытается достигнуть (например, 192.168.1.2).Тип коммуникационной сессии, т.е. конкретный сетевой протокол, используемый для взаимодействия между системами или устройствами источника и назначения (например, ТСР, UDP или ICMP).Возможно некоторые характеристики коммуникационных сессий уровня 4, такие как порты источника и назначения сессий (например, ТСР:80 для порта назначения, обычно принадлежащий web-серверу, ТСР:1320 для порта источника, принадлежащий персональному компьютеру, который осуществляет доступ к серверу).Иногда информация, относящаяся к интерфейсу роутера, на который пришел пакет, и информация о том, какому интерфейсу роутера она предназначена; это используется для роутеров с тремя и более сетевыми интерфейсами.Иногда информация, характеризующая направление, в котором пакет пересекает интерфейс, т.е. входящий или исходящий пакет для данного интерфейса.Иногда можно также указать свойства, относящиеся к созданию логов для данного пакета.
Пакетные фильтры обычно размещаются в сетевой инфраструктуре, использующей ТСР/IP. Однако они могут также быть размещены в любой сетевой инфраструктуре, которая имеет адресацию уровня 3, например, IPX (Novell NetWare) сети. В современных сетевых инфраструктурах firewall’ы на уровне 2 могут также использоваться для обеспечения балансировки нагрузки и/или в приложениях с высокими требованиями к доступности, в которых два или более firewall’а используются для увеличения пропускной способности или для выполнения восстановительных операций.
Некоторые пакетные фильтры, встроенные в роутеры, могут также фильтровать сетевой трафик, основываясь на определенных характеристиках этого трафика, для предотвращения DoS- и DDoS-атак.
Пакетные фильтры могут быть реализованы в следующих компонентах сетевой инфраструктуры:
пограничные роутеры;ОС;персональные firewall’ы.
Персональные firewall’ы и персональные устройства firewall’а
Обеспечение безопасности персональных компьютеров дома или в мобильном варианте сейчас становится столь же важным, как и обеспечение безопасности компьютеров в офисе; домашние пользователи, подключающиеся по dial-up к провайдеру, могут обеспечить защиту с помощью небольшого firewall’а, доступного им. Это необходимо, потому что провайдер может иметь много различных политик безопасности, не всегда соответствующих нуждам конкретного пользователя. Тем самым персональные firewall’ы разрабатываются для обеспечения защиты удаленных систем и выполняют во многом те же самые функции, что и большие firewall’ы.
Эти программные продукты обычно реализованы в одном из двух вариантов. Первый вариант представляет собой Personal Firewall, который инсталлируется на защищаемую систему; персональные firewall’ы обычно не предполагают защиту каких-либо других систем или ресурсов. Более того, персональные firewall’ы обычно не обеспечивают управление сетевым трафиком, который проходит через компьютер – они только защищают систему, на которой они инсталлированы.
Второй вариант называется устройством персонального firewall’а, чей подход более похож на традиционный firewall. В большинстве случаев устройства персонального firewall’а разрабатываются для защиты небольших сетей, таких как домашние сети. Эти устройства обычно изготавливаются на специализированной аппаратуре и имеют некоторые другие компоненты сетевой архитектуры в дополнение к самому firewall’у, включая следующие:
WAN-роутер кабельного модема;LAN-роутер (поддержка динамического роутинга);сетевой концентратор (hub);сетевой коммутатор (switch);DHCP;агент SNMP;агенты прикладного прокси.
Размещение этих инфраструктурных компонент в устройстве firewall’а позволяет использовать единственное аппаратное устройство для эффективного решения нескольких задач.
Хотя персональные firewall’ы и устройства персональных firewall’ов теряют некоторые преимущества и возможности масштабируемости традиционных firewall’ов, они могут быть достаточно эффективны для обеспечения общей безопасности организации.
Персональные firewall’ы и устройства персональных firewall’ ов обычно предназначены для филиалов офисов. Тем не менее некоторые организации используют эти устройства для создания Интранета, обеспечивая стратегию обороны вглубь. Персональные firewall’ы и устройства персональных firewall’ов могут также использоваться как конечные точки VPN.
Удобство управления устройством или приложением является важным фактором при оценки или выборе персонального firewall’а и устройства персонального firewall’а. Идеально, когда управление позволяет реализовать определяемую организацией политику безопасности на всех системах, которые присоединяются к сети и системе. Поэтому управление персональным firewall’ом или устройством персонального firewall’а должно быть по возможности централизовано. Это позволяет организации реализовывать определенную политику и поддерживать согласованное состояние систем, которые подсоединены удаленно. Наилучший способ обеспечить подобную функциональность является создание профиля безопасной конфигурации, который сопровождает конечного пользователя при его входе на любую систему. При таком подходе политика безопасности всегда будет эффективно реализовываться в момент доступа пользователя к ресурсам.
Что можно сказать об удаленных пользователях, которые подсоединяются к dial-in серверу организации или к провайдерам? Если политика безопасности провайдера является менее ограничительной, чем в организации, то риск, что компьютер будет инфицирован вирусом или будет выполнена другая атака, будет больше. Существует также проблема, что многие пользователи используют свои персональные компьютеры как для работы, так и для целей, далеких от служебных.
Одно из возможных решений состоит в использовании отдельных компьютеров в офисе и вне офиса.
Если такое решение недоступно, то персональный firewall должен использоваться все время и должен быть сконфигурирован с учетом наиболее ограничительных установок, используемых в организации. Если, например, разделение файлов в Windows запрещено firewall’ом, то это должно оставаться запрещенным, даже если компьютер используется в нерабочих целях.Также, если установки web-безопасности отвергают определенные типы содержимого, данный запрет должен оставаться в силе все время. Такая политика должна быть реализована для dial-in сервера; он, в свою очередь, должен быть размещен таким образом, чтобы firewall и прокси фильтровали входящий трафик от dial-in соединений.
Пограничные роутеры
Основным преимуществом пакетных фильтров является их скорость. Так как пакетные фильтры обычно проверяют данные до уровня 3 модели OSI, они могут функционировать очень быстро. Также пакетные фильтры имеют возможность блокировать DoS-атаки и связанные с ними атаки. По этим причинам пакетные фильтры, встроенные в пограничные роутеры, идеальны для размещения на границе с сетью с меньшей степенью доверия. Пакетные фильтры, встроенные в пограничные роутеры, могут блокировать основные атаки, фильтруя нежелательные протоколы, выполняя простейший контроль доступа на уровне сессий и затем передавая трафик другим firewall’ам для проверки более высоких уровней стека OSI.
Рис. 1.1. Использование пограничного роутера с возможностями пакетного фильтра
На рис. 1.1 показана топология сети, использующая пограничный роутер с возможностями пакетного фильтра в качестве первой линии обороны. Роутер принимает пакеты от недоверяемой сети, которые обычно приходят от другого роутера или от Интернет Сервис Провайдера (ISP). Затем роутер выполняет контроль доступа в соответствии со своей политикой, например, блокирует SNMP, разрешает НТТР и т.п. Затем он передает пакеты более мощному firewall’у для дальнейшего управления доступом и фильтрования операций на более высоких уровнях стека OSI. На рис. 1.1 также показана промежуточная сеть между пограничным роутером и внутреннем firewall’ом, называемая DMZ-сетью.
Преимущества пакетных фильтров:
Основным преимуществом пакетных фильтров является их скорость.Пакетный фильтр прозрачен для клиентов и серверов, так как не разрывает ТСР-соединение.
Недостатки пакетных фильтров:
Так как пакетные фильтры не анализируют данные более высоких уровней, они не могут предотвратить атаки, которые используют уязвимости или функции, специфичные для приложения. Например, пакетный фильтр не может блокировать конкретные команды приложения; если пакетный фильтр разрешает данный трафик для приложения, то все функции, доступные данному приложению, будут разрешены.Так как firewall’у доступна ограниченная информация, возможности логов в пакетных фильтрах ограничены.
Логи пакетного фильтра обычно содержат ту же информацию, которая использовалась при принятии решения о возможности доступа (адрес источника, адрес назначения, тип трафика и т.п.).Большинство пакетных фильтров не поддерживают возможность аутентификации пользователя. Данная возможность обеспечивается firewall’ами, анализирующими более высокие уровни.Они обычно уязвимы для атак, которые используют такие проблемы ТСР/IP, как подделка (spoofing) сетевого адреса. Многие пакетные фильтры не могут определить, что в сетевом пакете изменена адресная информация уровня 3 OSI. Spoofing-атаки обычно выполняются для обхода управления доступа, осуществляемого firewall’ом.При принятии решений о предоставлении доступа используется небольшое количество информации. Пакетные фильтры трудно конфигурировать. Можно случайно переконфигурировать пакетный фильтр для разрешения типов трафика, источников и назначений, которые должны быть запрещены на основе политики безопасности организации.
Следовательно, пакетные фильтры больше всего подходят для высокоскоростных окружений, когда создание логов и аутентификация пользователя для сетевых ресурсов не столь важна.
Так как современная технология firewall’а включает много возможностей и функциональностей, трудно найти firewall, который имеет возможности только пакетного фильтра. Примером может являться сетевой роутер, осуществляющий проверку списка контроля доступа для управления сетевым трафиком. Высокая производительность пакетных фильтров также способствует тому, что они реализуются в устройствах, обеспечивающих высокую доступность и особую надежность; некоторые производители предлагают аппаратные и программные решения как высоко доступные, так и особо надежные. Также большинство SOHO (Small Office Home Office) устройства firewall’ов и firewall’ов, встроенных по умолчанию в ОС, являются пакетными фильтрами.
Пример набора правил пакетного фильтра
Предположим, что в организации существует следующая топология (рис. 1.2).
Рис. 1.2. Топология сети с использованием пакетного фильтра
| 1 | Any | Any | 192.168.1.0(рабочая станция) | >1023 | Allow | Правило разрешает возвращать ТСР-соединения во внутреннюю подсеть, т.е. пользователи внутренней сети могут выходить в Интернет |
| 2 | 192.168.1.1(пакетный фильтр) | Any | Any | Any | Deny | Защищает сам пакетный фильтр от непосредственного соединения с кем-либо |
| 3 | Any | Any | 192.168.1.1 | Any | Deny | Предотвращает непосредственный доступ всех пользователей к пакетному фильтру |
| 4 | 192.168.1.0 | Any | Any | Any | Allow | Внутренние пользователи могут иметь доступ к внешним серверам |
| 5 | Any | Any | 192.168.1.2(SMTP-сервер) | SMTP | Allow | Разрешает всем (внешним и внутренним) пользователям посылать e-mail внутренним пользователям |
| 6 | Any | Any | 192.168.1.3(НТТР-сервер) | НТТР | Allow | Разрешает внешним пользователям иметь доступ к WWW-серверу |
| 7 | Any | Any | Any | Any | Deny | "Запретить все": правило – все, что не разрешено, то запрещено |
В таблице приведен пример набора правил пакетного фильтра для вымышленной сети с IP-адресами 192.168.1.0/255, т.е. локальная сеть имеет адреса в диапазоне от 192.168.1.0 до 192.168.1.254. В большинстве случаев набор правил должен быть детальнее. Обычно firewall принимает пакет, просматривает его адреса и порты источника и назначения и определяет используемый прикладной протокол. Далее firewall начинает просматривать правила сверху вниз. Если найдено правило, которое соответствует анализируемой в пакете информации, то выполняется указанное в правиле действие:
Accept (в некоторых пакетных фильтрах может быть Allow или Pass): firewall пропускает пакет через firewall, при этом может происходить создание лога, либо не происходить.Deny: firewall отбрасывает пакет без его передачи. После того как пакет отброшен, исходной системе возвращается сообщение об ошибке ("host unreachable").
Событие "Deny" может как создавать, так и не создавать запись лога, в зависимости от конфигурации набора правил firewall’а.Discard (в некоторых пакетных фильтрах может быть Unreach, Block или Reject): firewall не только отбрасывает пакет, но и не возвращает сообщение об ошибке исходной системе. Данное действие используется для реализации методологии "черной дыры", когда firewall не обнаруживает свое присутствие для внешней стороны. Как и для других действий, "Discard" может создавать и не создавать записи в логах.
В приведенной выше таблице первое правило разрешает, чтобы пакеты от внешних систем возвращались во внутренние системы, тем самым разрешая завершать создание соединения. Таким образом, здесь предполагается, что если инициализация соединения с внешней системой была разрешена, то возвращаемые пакеты от внешней системы должны быть также разрешены для завершения создания ТСР-соединения. Второе правило запрещает firewall’у пересылать любые пакеты с адресом источника firewall’а; данное условие предотвращает возможность атакующего подделать адрес firewall’а, заменив свой адрес на адрес firewall’а, чтобы firewall передал пакет внутреннему получателю. Здесь предполагается, что на данном хосте не установлено никаких других систем, к которым необходим доступ. В этом случае редактирование правил firewall’а возможно только с консоли хоста. Это не всегда бывает возможно. Например, может понадобиться доступ к хосту по протоколу SSH для редактирования правил самого firewall’а. Третье правило просто блокирует все пакеты от непосредственного доступа к firewall’у.
Четвертое правило разрешает внутренним системам соединяться с внешними системами, используя любые внешние адреса и любой протокол. Правила 5 и 6 разрешают внешним пакетам проходить firewall, если они содержат SMTP- или НТТР-данные. Тем самым можно сделать вывод, что политика информационной безопасности для сети следующая:
Любой тип доступа изнутри наружу разрешен.Никакой доступ снаружи внутрь не разрешен, за исключением SMTP и НТТР.SMTP- и НТТР-серверы расположены позади firewall’а.На сам firewall не разрешен доступ.
Важно заметить, что если последнее правило будет случайно пропущено, весь трафик извне будет разрешен. Когда набор правил более длинный и более детальный, могут быть сделаны ошибки, которые приведут к нарушениям безопасности. Набор правил должен быть очень тщательно проверен перед его применением и регулярно проверяться не только для гарантии того, что допустимы корректные протоколы, но и также для минимизации логических ошибок при добавлении новых правил.
Важным свойством пакетных фильтров является то, что фильтрация может осуществляться как для исходящего, так и для входящего трафика. Организация может выбрать ограничение типов трафика, передаваемых из внутренней сети, например, блокирование всего исходящего FTP-трафика. На практике исходящая фильтрация чаще всего применяется к IP-адресам и приложениям для блокировки возможности соединения всех пользователей, внутренних и внешних, с некоторыми системами, такими как сам пакетный фильтр, backup-серверы и другие чувствительные системы.
Прокси-сервер прикладного уровня
Прокси прикладного уровня являются более мощными firewall’ами, которые комбинируют управление доступом на низком уровне с функциональностью более высокого уровня (уровень 7 – Application).
Рис. 1.3. Типичные прокси-агенты
При использовании firewall’а прикладного уровня обычно, как и в случае пакетного фильтра не требуется дополнительное устройство для выполнения роутинга: firewall выполняет его сам. Все сетевые пакеты, которые поступают на любой из интерфейсов firewall’а, находятся под управлением этого прикладного прокси. Прокси-сервер имеет набор правил управления доступом для определения того, какому трафику может быть разрешено проходить через firewall.
Аутентификация пользователя может иметь много форм, например такие:
с помощью User ID и пароля;с помощью аппаратного или программного токена;по адресу источника;биометрическая аутентификация.
Прокси-сервер, который анализирует конкретный протокол прикладного уровня, называется агентом прокси.
Firewall’ы прикладного уровня имеют много преимуществ по сравнению с пакетными фильтрами и stateful inspection пакетными фильтрами.
Преимущества прокси-сервера прикладного уровня:
Прокси имеет возможность запросить аутентификацию пользователя. Часто существует возможность указывать тип аутентификации, который считается необходимым для данной инфраструктуры. Прикладные прокси имеют возможность аутентифицировать самих пользователей, в противоположность пакетным фильтрам и stateful inspection пакетным фильтрам, обычно проверяющим только адрес сетевого уровня, с которого пришел пользователь. Эти адреса сетевого уровня могут быть легко подменены без обнаружения подмены пакетным фильтром.Возможности аутентификации, свойственные архитектуре прикладного уровня, лучше по сравнению с теми, которые существуют в пакетных фильтрах и stateful inspection пакетных фильтрах. Благодаря этому прикладные прокси могут быть сделаны менее уязвимыми для атак подделки адреса.Firewall’ы прикладного уровня обычно имеют больше возможностей анализировать весь сетевой пакет, а не только сетевые адреса и порты.
Например, они могут определять команды и данные, специфичные для каждого приложения.Как правило, прокси прикладного уровня создают более подробные логи.
Более развитая функциональность прикладного прокси имеет также несколько недостатков по сравнению с пакетными фильтрами и stateful inspection пакетными фильтрами.
Недостатки прокси-сервера прикладного уровня:
Так как прикладные прокси "знают о пакете все", firewall вынужден тратить много времени для чтения и интерпретации каждого пакета. По этой причине прикладные прокси обычно не подходят для приложений, которым необходима высокая пропускная способность, или приложений реального времени. Чтобы уменьшить загрузку firewall’а, может использоваться выделенный прокси-сервер для обеспечения безопасности менее чувствительных ко времени сервисов, таких как e-mail и большинство web-трафика.Прикладные прокси обрабатывают ограниченное количество сетевых приложений и протоколов и не могут автоматически поддерживать новые сетевые приложения и протоколы. Для каждого прикладного протокола, который должен проходить через firewall, необходим свой агент прокси. Большинство производителей прикладных прокси предоставляют общих агентов прокси для поддержки неизвестных сетевых приложений или протоколов. Однако эти общие агенты не имеют большинства преимуществ прикладных прокси: как правило, они просто туннелируют трафик через firewall.
Скрытая трансляция сетевых адресов
При скрытой трансляции все системы позади firewall’а разделяют некоторый внешний IP-адрес, к которому выполняется роутинг. Таким образом, при скрытой трансляции сетевых адресов все хосты позади firewall’а будут выглядеть как один хост. Такой тип трансляции является достаточно распространенным, но имеет одно существенное слабое место. Данная технология не позволяет сделать доступными для внешних пользователей те ресурсы, которые размещены позади firewall’а. Отображение от внешних систем во внутренние системы невозможно, следовательно, хосты, которые должны быть доступны внешним системам, не могут применять данное отображение адресов. Другое слабое место данного подхода состоит в том, что firewall в этом случае должен использовать свой собственный внешний интерфейсный сетевой адрес в качестве "заменяемого" или транслируемого адреса для всех систем и ресурсов, которые расположены позади него. Данное требование приводит к уменьшению гибкости данного механизма.
Stateful Inspection firewall’ы
Stateful Inspection firewall’ы являются пакетными фильтрами, которые анализируют содержимое 4-го уровня (Transport) модели OSI.
Stateful inspection разрабатывались исходя из необходимости рассматривать основные особенности протоколов TCP/IP. Когда ТСР создает сессию с удаленной системой, также открывается порт на исходной системе для получения сетевого трафика от системы назначения. В соответствии со спецификацией ТСР, данный порт источника клиента будет некоторым числом, большим, чем 1023 и меньшим, чем 16384. Порт назначения на удаленном хосте, как правило, имеет фиксированный номер. Например, для SMTP это будет 25.
Пакетные фильтры должны разрешать входящий сетевой трафик для всех таких портов "с большими номерами" для транспорта, ориентированного на соединение, так как это будут возвращаемые пакеты от системы назначения. Открытие портов создает риск несанкционированного проникновения в локальную сеть.
В таблице 1.6 показана первая строчка набора правил пакетного фильтра из приведенной выше таблицы, которая разрешает любое входящее соединение, если порт назначения больше 1023. Stateful inspection firewall’ы решают эту проблему созданием таблицы для исходящих ТСР-соединений, соответствующих каждой сессии. Эта "таблица состояний" затем используется для проверки допустимости любого входящего трафика. Решение stateful inspection является более безопасным, потому что отслеживать используемые порты каждого клиента лучше, чем открывать для внешнего доступа все порты "с большими номерами".
| Any | Any | 192.168.1.0 | >1023 | Allow | Правило разрешает возвращать ТСР-соединения во внутреннюю подсеть |
В сущности, stateful inspection firewall’ы добавляют понимание уровня 4 в архитектуру пакетного фильтра. Stateful inspection firewall’ы разделяют сильные и слабые стороны пакетных фильтров, но вследствие реализации таблицы состояний stateful inspection firewall’ы обычно считаются более безопасными, чем пакетные фильтры.
В таблице 1. 7 показан пример таблицы состояний firewall’а stateful inspection.
| 192.168.1.100 | 1030 | 210.9.88.29 | 80 | Establish |
| 192.168.1.102 | 1031 | 216.32.42.123 | 80 | Establish |
| 192.168.1.101 | 1033 | 173.66.32.122 | 25 | Establish |
| 192.168.1.106 | 1035 | 177.66.32.122 | 79 | Establish |
| 223.43.21.231 | 1990 | 192.168.1.6 | 80 | Establish |
| 219.22.123.32 | 2112 | 192.168.1.6 | 80 | Establish |
| 210.99.212.18 | 3321 | 192.168.1.6 | 80 | Establish |
| 24.102.32.23 | 1025 | 192.168.1.6 | 80 | Establish |
| 223.212.212 | 1046 | 192.168.1.6 | 80 | Establish |
Разрешает прохождение пакетов только для установленных соединений;Прозрачен для клиентов и серверов, так как не разрывает ТСР-соединение.
Недостатки stateful inspection firewall’а:
Реально используется только в сетевой инфраструктуре TCP/IP. Хотя, надо отметить, что stateful inspection firewall можно реализовать в других сетевых протоколах тем же способом, что и пакетные фильтры.
Статическая трансляция сетевых адресов
При статической трансляции сетевых адресов каждая внутренняя система или частная сеть имеет соответствующий, связанный с ней внешний IP-адрес. Данная технология используется редко из-за недостатка доступных IP-адресов. При статической трансляции сетевых адресов возможно предоставление доступа к ресурсам, размещенным позади firewall’а. Другими словами, внешняя система может иметь доступ ко внутреннему web-серверу; при этом адрес отображается с использованием статической трансляции сетевых адресов. Ниже приведен пример таблицы статической трансляции сетевых адресов, отображающей внутренние IP-адреса, к которым не выполняется роутинг, во внешние адреса, к которым выполняется роутинг.
| 192.168.1.100 | 207.119.32.81 |
| 192.168.1.101 | 207.119.32.82 |
| 192.168.1.102 | 207.119.32.83 |
Трансляция сетевых адресов (NAT)
Технология трансляции сетевых адресов (NAT) была разработана для решения двух важных проблем, возникших в сетевой инженерии и безопасности. Во-первых, NAT является эффективным средством для скрытия схемы сетевой адресации позади firewall’а. В сущности, трансляция сетевых адресов позволяет организации развертывать схему адресации позади firewall’а в соответствии со своим выбором, в то же время поддерживая возможность соединяться с внешними ресурсами через firewall. Во-вторых, это решает проблему исчерпания пространства IP-адресов.
NAT выполняется в трех основных формах: статическая трансляция сетевых адресов, скрытая трансляция сетевых адресов и трансляция портов.
Установление ТСР-соединения
ТСР является надежным протоколом в сетях, основанных на коммутации пакетов. Так как и пакетные фильтры, и stateful inspection firewall’ы анализируют параметры ТСР-протокола, рассмотрим подробно этот протокол. Стек протоколов TCP/IP выглядит следующим образом:
| Прикладной уровень |
| ТСР |
| IP |
| Коммуникационная сеть |
Протокол IP обеспечивает способ адресации источника и получателя. IP также имеет дело с фрагментацией и реассемблированием пакетов, которые передаются на транспортный уровень.
Протокол ТСР обеспечивает надежность и упорядоченность для получателя потока данных, посылаемого по ТСР-соединению.
Надежность обеспечивается с помощью того, что каждый пакет содержит свой последовательный номер и номер полученного пакета. С каждым октетом данных связывается последовательный номер. Этот номер указывается для первого октета данных в передаваемом сегменте. Сегменты также содержат номер подтверждения, который является последовательным номером следующего ожидаемого октета данных, передаваемых в обратном направлении. Когда один из концов ТСР-соединения передает сегмент, содержащий данные, он помещает его копию в очередь повторной передачи и запускает таймер; когда подтверждение о получении этих данных получено, сегмент удаляется из очереди. Если подтверждение не получено по истечении таймера, сегмент передается повторно.
Для идентификации начальной и конечной точек ТСР-соединения вводится понятие номера порта. Номера портов выбираются независимо для каждого соединения ТСР, при этом они могут не быть уникальными. Для обеспечения уникальной идентификации внутри каждого соединения ТСР, выполняется конкатенация IP-адреса и номера порта. Эта конкатенация определяет сокет.
Соединение полностью определяется парой сокетов на своих концах. Локальный сокет может участвовать во многих соединениях с различными удаленными сокетами. Соединение используется для пересылки данных в обоих направлениях.
ТСР может использовать любые номера портов. Тем не менее определены некоторые базовые принципы назначения номеров портов.
Существуют " хорошо известные" номера портов, которые ТСР связывает только с "соответствующими" процессами.
Каждый конец ТСР-соединения является либо клиентом, либо сервером. Соединение инициируется клиентом. Сервер ждет установления соединения от клиента. Поэтому ТСР-соединение может быть открыто либо в пассивном режиме — сервером, либо в активном — клиентом.
Запрос пассивного открытия означает, что процесс сервера ждет запросов на входящие соединения, а не пытается сам инициировать соединение. Часто процесс, запрашивающий пассивное открытие, будет принимать запросы соединения от любого вызывающего.
Процесс, который хочет предоставлять сервис другим неизвестным процессам, создает запрос пассивного открытия. При этом будет создаваться соединение с любым процессом, который запросил соединение с данным локальным сокетом.
Процедура установления соединений использует флаг управления синхронизацией (SYN) и включает обмен тремя сообщениями.
Соединение инициируется при получении сегмента, содержащего установленный флаг SYN. При инициализации соединение устанавливается между локальным и удаленным сокетами. Оно становится "установленным", когда последовательные номера пакетов синхронизованы в обоих направлениях.
Очистка соединения включает обмен сегментами, содержащими управляющий флаг FIN.
ТСР-сегменты посылаются в виде датаграмм. Заголовок IP содержит несколько полей, включая адреса хостов источника и получателя. ТСР-заголовок следует за IP-заголовком и содержит информацию, специфичную для ТСР.
| Порт источника | Порт получателя | ||||||||||
| Sequence Number | |||||||||||
| Acknowledgement Number | |||||||||||
| Window | ||||||||||
| Checksum | Urgent Pointer | ||||||||||
| Options Padding | |||||||||||
| Данные | |||||||||||
Порт получателя – 16 бит.
Sequence Number – 32 бита. Последовательный номер первого октета данных в данном сегменте. Исключением является случай, когда присутствует флаг SYN. В этом случае последовательный номер есть начальный последовательный номер (Initial Sequence Number — ISN), и номер первого октета данных равен ISN+1.
Acknowledgement Number – 32 бита. Если установлен управляющий бит ACK, то данное поле содержит значение следующего последовательного номера, который ждет получатель. Это значение посылается всегда, если соединение установлено.
Data Offset – 4 бита. Число 32-битных слов в ТСР-заголовке. Оно определяет положение начала данных. Длина ТСР-заголовка всегда кратна 32.
Управляющие биты: 6 бит.
URG — указывает, что сегмент содержит экстренные данные и поле Urgent Pointer заголовка определяет их положение в сегменте.
ACK — указывает, что поле номера подтверждения содержит номер последнего полученного сегмента.
PSH — указывает, что данные из буфера могут быть переданы немедленно.
RST — указывает на необходимость сброса соединения.
SYN — указывает, что выполняется синхронизация последовательных номеров.
FIN — указывает, что от отправителя больше не будут передаваться данные.
Window — 16 бит. Количество октетов данных, начиная с номера, указанного в подтверждении, которое отправитель данного сегмента может получить. Используется для управления интенсивностью передаваемого потока данных.
Checksum – 16 бит. Контрольная сумма всех слов в заголовке и данных.
Urgent Pointer – 16 бит. Данное поле содержит положительное смещение экстренных данных относительно последовательного номера в данном сегменте.
Options – переменной длины. Опции могут быть указаны в конце ТСР-заголовка. Определены два варианта формата опций:
Один октет для типа опции.Октет типа опции, октет длины опции и октеты с конкретными данными опции.
Padding – переменной длины. Данное добавление ТСР-заголовка используется для того, чтобы гарантировать, что ТСР-заголовок кончается, и данные начинаются на 32-битной границе.
Установление ТСР-соединения происходит с использованием так называемого "тройного рукопожатия". Соединение инициирует клиент, посылая сообщение с установленным битом SYN. Сервер отвечает клиенту сообщением с установленными битами SYN и ACK. Сервер также указывает начальный порядковый номер в поле Sequence Number.
Наконец, клиент посылает серверу сообщение с установленным битом ACK, в поле Sequence Number указывает свой начальный номер, в поле Acknowledgement Number указывает полученный от сервера начальный порядковый номер, увеличенный на единицу.
В течение своего жизненного цикла соединение проходит через несколько состояний.
На стороне клиента:
CLOSED
SYN-SENT
ESTABLISHED
FIN-WAIT-1
CLOSE-WAIT
CLOSING
LAST-ACK
CLOSED,
На стороне сервера:
CLOSED
LISTEN
SYN-RESEIVED
ESTABLISHED
FIN-WAIT-1
CLOSE-WAIT
CLOSING
FIN-WAIT-2
TIME-WAIT
CLOSED
Рассмотрим смысл каждого состояния.
Состояние CLOSED является фиктивным, потому что оно представляет собой состояние, для которого не существует структуры данных Transmission Control Block (ТСВ) и, следовательно, нет соединения.
LISTEN – состояние сервера, которое представляет собой ожидание запроса соединения от любой удаленной стороны.
SYN-SENT – состояние клиента, которое представляет собой ожидание ответа на запрос соответствующего соединения после того как послан запрос на соединение.
SYN-RECEIVED – состояние сервера, которое представляет собой ожидание подтверждения на запрос соединения после того как и клиент, и сервер получили и послали запрос на соединение.
ESTABLISHED – состояние как клиента, так и сервера, которое представляет собой открытое соединение: полученные данные могут быть доставлены на прикладной уровень. Обычное состояние для фазы пересылки данных по соединению.
Инициатором закрытия соединения может быть как клиент, так и сервер.
FIN-WAIT-1 – состояние как клиента, так и сервера, при котором сторона, инициировавшая закрытие (был послан пакет в флагом FIN), ожидает подтверждения на запрос закрытия соединения.
CLOSE-WAIT – состояние как клиента, так и сервера, при котором было послано подтверждение ACK на запрос закрытия (FIN). При этом канал становится симплексным: передача возможна только в одном направлении – от того, кто послал подтверждение ACK. Происходит ожидание закрытия канала от локального процесса.
FIN-WAIT-2 — состояние как клиента, так и сервера, при котором было получено подтверждение ACK запроса закрытия соединения от удаленной стороны.При получении пакета с установленным флагом FIN канал считается окончательно разрушенным.
LAST-ACK – состояние как клиента, так и сервера, представляет собой подтверждение (пакет с установленным флагом FIN) завершения соединения, ранее посланного удаленной стороне.
CLOSING – представляет собой ожидание подтверждения запроса завершения соединения от удаленной стороны.
TIME-WAIT – представляет собой ожидание определенное время, чтобы быть уверенным, что удаленная сторона получила подтверждение вашего запроса на закрытие соединения.
ТСР-соединение переходит из одного состояния в другое в результате возникновения событий. Событиями являются вызовы функций OPEN, SEND, RECEIVE, CLOSE, ABORT и STATUS, входящие сегменты, содержащие флаги SYN, ACK, RST и FIN, а также таймауты.
и сети от попыток несанкционированного
Firewall’ы защищают компьютеры и сети от попыток несанкционированного доступа с использованием уязвимых мест, существующих в семействе протоколов ТСР/IP. Дополнительно они помогают решать проблемы безопасности, связанные с использованием уязвимых систем и с наличием большого числа компьютеров в локальной сети. Существует несколько типов firewall’ов, начиная от пакетных фильтров, встроенных в пограничные роутеры, которые могут обеспечивать управление доступом для IP-пакетов, до мощных firewall’ов, которые могут закрывать уязвимости в большом количестве уровней семейства протоколов ТСР/IP, и еще более мощных firewall'ов, которые могут фильтровать трафик на основании всего содержимого пакета.
Технологические возможности firewall’ов с начала 1990-х годов существенно улучшились. Сперва были разработаны простые пакетные фильтры, которые постепенно развивались в более сложные firewall’ы, способные анализировать информацию на нескольких сетевых уровнях. Сегодня firewall’ы являются стандартным элементом любой архитектуры безопасности сети.
Современные firewall’ы могут работать совместно с такими инструментальными средствами, как системы обнаружения проникновений и сканеры содержимого e-mail или web с целью нахождения вирусов или опасного прикладного кода. Но в отдельности firewall не обеспечивает полной защиты от всех проблем, порожденных Интернетом. Как результат, firewall’ы являются только одной частью архитектуры информационной безопасности. Обычно они рассматриваются как первая линия обороны, однако их лучше воспринимать как последнюю линию обороны в организации; организация в первую очередь должна делать безопасными свои внутренние системы. Для внутренних серверов, персональных компьютеров и других систем должны своевременно выполняться все обновления как самих систем, так и других систем обеспечения безопасности, например, антивирусного ПО.
Займемся основными понятиями, связанными с firewall’ами и политикой firewall’а, на основании которой реализуется обеспечение безопасности сети.
Рассмотрим понятия, относящиеся к выбору, развертыванию и управлению firewall’ом и его функциональному окружению. Рассмотрим также возможные подходы к созданию различных топологий сети с использованием firewall’ов.
Данное описание в основном предназначено для технических специалистов, а также для управляющего персонала, которому могут потребоваться технические знания для принятия решений.
Сначала сделаем обзор стека протоколов OSI и покажем, на каком уровне функционируют различные типы firewall’ов, такие как пакетные фильтры, stateful inspection firewall’ы и прикладные прокси.
Затем опишем различные окружения firewall’а, например, комбинации конкретных компонентов обеспечивающие то или иное решение. Приведем примеры расположения firewall’ов и их взаимодействий с другими инструментальными средствами безопасности. Также опишем прочие функции современных firewall’ов, такие как использование их в качестве конечных точек VPN, трансляция IP-адресов, фильтрация содержимого web или e-mail.
Далее рассмотрим принципы, используемые при администрировании firewall’ов и конфигурировании политики firewall’а. Опишем политику firewall’а, которой он должен соответствовать в контексте общей политики безопасности, а также сформулируем минимальную политику, которая может соответствовать многим окружениям. Наконец, опишем предложения по реализации и поддержке администрирования firewall’а.
Выделенные прокси-серверы
Выделенные прокси-серверы отличаются от прикладных прокси в том, что они анализируют трафик только конкретного прикладного протокола и не обладают возможностями анализа всего трафика, что все-таки характерно для firewall’а прикладного уровня. По этой причине они обычно развертываются позади firewall’ов прикладного уровня. Типичное использование таково: основной firewall получает входящий трафик, определяет, какому приложению он предназначен, и затем передает обработку конкретного типа трафика соответствующему выделенному прокси-серверу, например, e-mail прокси серверу. Выделенный прокси-сервер при этом выполняет операции фильтрации и логирования трафика и затем перенаправляет его во внутренние системы. Этот сервер может также принимать исходящий трафик непосредственно от внутренних систем, фильтровать трафик и создавать логи, а затем передавать его firewall’у для последующей доставки. Обычно выделенные прокси-серверы используются для уменьшения нагрузки на firewall и выполнения более специализированной фильтрации и создания логов.
Как и в случае прикладных прокси, выделенные прокси позволяют выполнить аутентификацию пользователей. В случае использования выделенного прокси легче более точно ограничить исходящий трафик или проверять весь исходящий и входящий трафик, например, на наличие вирусов. Выделенные прокси-серверы могут также помочь в отслеживании внутренних атак или враждебного поведения внутренних пользователей. Фильтрация всего исходящего трафика сильно загружает общий firewall прикладного уровня и увеличивает стоимость администрирования.
В дополнение к функциям аутентификации и создания логов, выделенные прокси-серверы используются для сканирования web и e-mail содержимого, включая следующие функции:
фильтрование Java-апплетов или приложений;фильтрование управлений ActiveX;фильтрование JavaScript;блокирование конкретных MIME-типов – например, "application/msword";сканирование и удаление вирусов;блокирование команд, специфичных для приложения, например, блокирование НТТР-команды PUT;блокирование команд, специфичных для пользователя, включая блокирование некоторых типов содержимого для конкретных пользователей.
Рис. 1.4. Примеры выделенных прикладных прокси-серверов
На рис. 1.4 показан пример топологии сети, которая имеет выделенные прокси-серверы для НТТР и e-mail, расположенные позади основного firewall’а. В этом случае e-mail прокси может быть SMTP-шлюзом организации для входящей почты. Основной firewall будет перенаправлять входящую почту к прокси для сканирования содержимого, после чего почта может становиться доступной внутренним пользователям на SMTP-сервере, например, по протоколам РОР3 или IMAP. НТТР-прокси должен обрабатывать исходящие соединения ко внешним web-серверам и, возможно, фильтровать активное содержимое. Прокси-сервером может выполняться кэширование часто используемых web-страниц, тем самым уменьшая трафик к firewall’у.
DNS-серверы
DNS является критическим сервисом в любом окружении, в котором используется Интернет. В силу чувствительной природы данного сервиса, с одной стороны, и предоставления им информации о внешне доступных сервисах с другой, необходимы специальные меры безопасности, которые будут рассматриваться в следующих лекциях.
Рис. 2.6. Пример топологии сети с двумя DNS-серверами
Во-первых, внутренние DNS-серверы должны быть отделены от внешних DNS-серверов. Например, DNS-сервер, который доступен всему миру, не должен содержать записей о системах, которые не должны быть достигнуты извне. Если такие записи о внутренних системах имеются во внешнем DNS-сервере, это даст возможность атакующему определить список целей. Следует поддерживать отдельно внутренний и внешний DNS-серверы либо использовать технологию, известную как split DNS, которая гарантирует, что внутренние системы никогда не смогут быть идентифицированы посторонними.
Во-вторых, также необходимо контролировать разрешенные типы доступа к DNS-серверу. Приложение DNS-сервера может выполняться с использованием двух транспортных протоколов: клиент обращается к серверу по протоколу UDP, а взаимодействие двух серверов DNS, выполняющих зонные пересылки, реализовано с использованием ТСР. Доступ к серверу DNS с использованием ТСР должен быть ограничен только для тех серверов DNS, которые должны выполнять зонные пересылки. Основной риск, который существует при функционировании DNS, состоит в модификации передаваемой информации. Например, если сервер допускает неаутентифицированные запросы и ответы DNS, атакующий может модифицировать информацию, в результате чего сетевой трафик будет перенаправлен на другой хост. На рис. 2.6 показан пример топологии сети с двумя DNS-серверами. Внутренний DNS-сервер должен быть сконфигурирован для разрешения имен внутренних клиентов, чтобы внутренние пользователи могли соединяться с внутренними серверами, всеми серверами в DMZ и Интернетом. Внешний DNS-сервер должен обеспечивать разрешение имен самого DNS-сервера и серверов во внешней DMZ, но не во внутренней сети. Как результат, серверы во внешней DMZ будут видимы в Интернете.
Физическая безопасность окружения firewall’а
О физической безопасности firewall’а иногда забывают. Если эти устройства расположены в небезопасной области, они восприимчивы к поломкам со стороны атакующего и имеют высокий риск получить случайный ущерб. Следовательно, устройства firewall’ов должны находиться за закрытыми дверями.
Другим фактором физической безопасности является качество электрических и сетевых соединений и контроль окружения. Необходимо иметь резервные источники питания и возможность резервных соединений с внешними сетями.
Наконец, firewall должен быть защищен от различных стихийных бедствий.
Инциденты безопасности
Не существует простого ответа на вопрос, что такое инцидент безопасности.
В общем случае инцидентом безопасности является любое событие, в котором неавторизованный индивид получает или пытается получить доступ к компьютерным системам или ресурсам, на которые у него нет привилегий. Серьезность инцидента может отличаться, и компания сама дает строгое определение инциденту безопасности.
При высоком уровне шкалы строгости минимальный инцидент безопасности может состоять из зондирования сети или системы, которое используется для изучения топологии сети. Если такое зондирование выполняет неавторизованный пользователь, инцидент безопасности имеет место. При большом количестве подобных событий большинство компаний предпочитают считать, что данные события не являются инцидентом безопасности.
При среднем уровне шкалы строгости инцидент безопасности может иметь форму активных попыток получения неавторизованного доступа к компьютерной системе. При низком уровне шкалы инцидентом может быть любая успешная попытка получения неавторизованного доступа к системе или ресурсам. Эти события потенциально могут ликвидировать доступность ресурсов и, следовательно, являются серьезными. При идентификации инцидента некоторые организации могут попытаться преследовать нарушителя. В любом случае, инцидент должен быть зарегистрирован.
В сущности, определение инцидента безопасности определяется политикой безопасности организации.
Firewall’ы могут являться критичными элементами в контексте инцидента безопасности – они указывают на корреляцию событий. Корреляцию событий обеспечивает тот факт, что firewall’ы являются рубежом, который должны пересечь все сетевые атаки, чтобы войти в сеть. Это ставит firewall в уникальное положение по анализу неавторизованной деятельности. По этой причине все firewall’ы и другие системы создания логов, такие как IDS, должны выполнять синхронизацию времени. Наиболее общим механизмом для синхронизации времени является Network Time Protocol (NTP).
Интранет
Интранет является сетью, которая выполняет те же самые сервисы, приложения и протоколы, которые присутствуют в Интернете, но без наличия внешнего соединения с Интернетом. Например, сеть предприятия, поддерживающая семейство протоколов TCP/IP, можно рассматривать как Интранет.
Большинство организаций в настоящее время имеет некоторый тип Интранета. Во внутренней сети (интранет) могут быть созданы еще меньшие Интранеты, используя внутренние firewall’ы. Например, можно защитить свою собственную персональную сеть внутренним firewall’ом, и получившаяся защищенная сеть может рассматриваться как персональная интранет.
Так как Интранет использует те же самые протоколы и прикладные сервисы, что и Интернет, многие проблемы безопасности, унаследованные из Интернета, также присутствуют в Интранете.
Экстранет
Термин "Экстранет" применяется к сети, логически состоящей из трех частей: две интранет соединены между собой через Интернет с использованием VPN. Экстранет может быть определена как business-to-business Интранет. Эта сеть позволяет обеспечить ограниченный, управляемый доступ удаленных пользователей посредством той же формы аутентификации и шифрования, которые имеются в VPN.
Экстранет имеет те же самые характеристики, что и интранет, за исключением того, что экстранет использует VPN для создания защищенных соединений через публичный Интернет. Целью интранет является предоставление доступа к потенциально чувствительной информации удаленным пользователям или организациям, но при этом запрещая доступ всем остальным внешним пользователям и системам. Экстранет использует протоколы TCP/IP и те же самые стандартные приложения и сервисы, которые используются в Интернете. На рис. 2.5 показан пример топологии сети экстранета.
Рис. 2.5. VPN и экстранет, соединяющие две сети интранета
Компоненты инфраструктуры: концентраторы и коммутаторы
Дополнительно к роутерам и firewall’ам, связь между системами обеспечивают такие инфраструктурные устройства, как концентраторы (hubs) и коммутаторы (switches). Наиболее простым из них является сетевой концентратор. Концентраторы — это устройства, которые функционируют на уровне 1 модели OSI. Другими словами, они предназначены только для предоставления физического подсоединения сетевых систем или ресурсов.
У сетевых концентраторов существует много слабых мест. Первое и основное состоит в том, что концентраторы позволяют любому устройству, присоединенному к ним, просматривать весь сетевой трафик. По этой причине они не должны использоваться для построения DMZ-сетей или окружений firewall’а.
Более развитыми инфраструктурными устройствами являются сетевые коммутаторы. Это устройства уровня 2, то есть они обладают определенной информацией при создании присоединения сетевых систем или компонент. Основное свойство коммутаторов состоит в том, что системы, присоединенные к коммутатору, не могут "подсматривать" трафик друг друга; поэтому они лучше подходят для реализации DMZ-сетей и окружений firewall’ов.
Важно заметить, что коммутаторы не должны использоваться для предоставления каких-либо возможностей firewall’а или обеспечения изолирования трафика вне окружения firewall’а, так как при этом возможны DoS-атаки, которые могут привести к тому, что коммутаторы переполнят присоединенные сети пакетами.
Конфигурация с двумя DMZ-сетями
При наличии большого числа серверов с разными требованиями доступа можно иметь firewall пограничного роутера и два внутренних firewall’а и разместить все внешне доступные серверы во внешней DMZ между роутером и первым firewall’ом. Пограничный роутер будет фильтровать пакеты и обеспечивать защиту серверов, первый firewall будет обеспечивать управление доступом и защиту серверов внутренней DMZ в случае, если они атакованы. Организация размещает внутренне доступные серверы во внутренней DMZ, расположенной между основным и внутренним firewall’ами; firewall’ы будут обеспечивать защиту и управление доступом для внутренних серверов, защищенных как от внешних, так и от внутренних атак.
Рис. 2.3. Пример окружения firewall’а с двумя DMZ-сетями
Окружение firewall’а для данной сети показано на рис. 2.3.
Внешняя DMZ-сеть соединена с Интернетом через пакетный фильтр, служащий пограничным роутером, – выше были указаны причины, по которым использование пакетного фильтра является предпочтительным.Основной firewall является VPN-шлюзом для удаленных пользователей; такие пользователи должны иметь ПО VPN-клиента для соединения с firewall’ом.Входящий SMTP-трафик должен пропускаться основным firewall’ом.Исходящий НТТР-трафик должен проходить через внутренний firewall, который передает данный НТТР-трафик прикладному НТТР-прокси, размещенному во внутренней DMZ.
Основной и внутренний firewall’ы должны поддерживать технологию stateful inspection и могут также включать возможности прикладного прокси. Основной firewall должен выполнять следующие действия:
разрешать внешним пользователям соединяться с VPN-сервером, где они должны аутентифицироваться;пропускать внутренние SMTP-соединения и данные к прокси-серверу, где данные могут быть отфильтрованы и переданы системам назначения;выполнять роутинг исходящего НТТР-трафика от НТТР-прокси и исходящего SMTP-трафика от SMTP-сервера;после этого запретить весь другой исходящий НТТР- и SMTP-трафик;после этого разрешить весь другой исходящий трафик.
Внутренний firewall должен принимать входящий трафик только от основного firewall’а, прикладного НТТР-прокси и SMTP-сервера. Кроме того, он должен принимать SMTP- и НТТР-трафик только от прокси, но не от основного firewall’а. Наконец, он должен разрешать все исходящие соединения от внутренних систем.
Чтобы сделать данный пример применимым к окружениям с более высокими требованиями к безопасности, можно добавить следующие сервисы:
могут быть добавлены внутренний и внешний DNS-серверы, чтобы спрятать внутренние системы;может использоваться NAT для дальнейшего сокрытия внутренних систем;исходящий трафик от внутренних систем может фильтроваться, что может включать фильтрование трафика к определенным сайтам или сервисам в соответствии с политикой управления;может быть использовано несколько firewall’ов для увеличения производительности.
Конфигурация с одной DMZ-сетью
В большинстве случаев окружение firewall’а образует так называемую DMZ-сеть или сеть демилитаризованной зоны. DMZ-сеть является сетью, расположенной между двумя firewall’ами.
DMZ-сети предназначены для расположения систем и ресурсов, которым необходим доступ либо только извне, либо только изнутри, либо и извне, и изнутри, но которые не должны быть размещены во внутренних защищенных сетях. Причина в том, что никогда нельзя гарантировать, что эти системы и ресурсы не могут быть взломаны. Но взлом этих систем не должен автоматически означать доступ ко всем внутренним системам.
Рис. 2.1. Пример окружения firewall’а с одной DMZ
DMZ-сети обычно строятся с использованием сетевых коммутаторов и располагаются между двумя firewall’ами или между firewall’ом и пограничным роутером. Хорошей практикой является размещение серверов удаленного доступа и конечных точек VPN в DMZ-сетях. Размещение этих систем в DMZ-сетях уменьшает вероятность того, что удаленные атакующие будут иметь возможность использовать эти серверы в качестве точки входа в локальные сети. Кроме того, размещение этих серверов в DMZ-сетях позволяет firewall’ам служить дополнительными средствами для контроля прав доступа пользователей, которые получают доступ с использованием этих систем к локальной сети.
Политика безопасности firewall’а
При определении топологии сети крайне важна конкретная и четко выраженная политика информационной безопасности. Данная политика должна определять все, начиная от допустимого использования различных серверов до сценариев ответа на события, связанные с различными инцидентами безопасности. Политика firewall’а отличается от политики информационной безопасности в основном тем, что является описанием того, как политика информационной безопасности реализуется firewall’ом и другими механизмами безопасности.
Без наличия политики безопасности администраторы работают "втемную". Firewall’ы могут быть сложными и трудными с точки зрения управления, и инциденты, связанные с безопасностью, могут возникать ежедневно. Без политики, определяющей, кроме всего прочего, управление firewall’ом, он сам может создавать проблемы, связанные с безопасностью.
Политика firewall’а
Политика firewall’а определяет, как firewall должен обрабатывать трафик различных приложений, таких как web, e-mail или telnet. Политика также должна описывать, как сам firewall управляется и модифицируется.
До того, как политика firewall’а может быть создана, должен быть выполнен в той или иной форме анализ риска для приложений, которые требуются для всей деятельности организации. Результаты данного анализа должны включать как список приложений, так и то, каким образом должна обеспечиваться безопасность этих приложений. Процесс создания данного списка здесь не детализирован, но он требует знания уязвимостей, связанных с каждым приложением, и соотношения стоимости и преимуществ для методов, используемых в обеспечении безопасности приложений. Анализ риска информационной инфраструктуры организации должен быть сделан на основе оценки следующих элементов: угроз; уязвимостей и соответствующих контрмер, их уменьшающих; последствия, если чувствительные данные скомпрометированы. Целью является понимание и оценка этих элементов до определения политики firewall’а.
В результате анализа риска должен быть определен способ, которым система firewall’а обрабатывает трафик приложений. Детали того, какие приложения могут проходить через firewall, и точные условия, при которых такая деятельность осуществима, должны быть документированы в форме матрицы трафика приложений.
Должны выполняться следующие шаги при создании политики firewall’а:
Определение необходимых сетевых приложений.Определение уязвимостей, связанных с приложениями.Анализ соотношения цены и качества для методов, используемых в обеспечении безопасности приложений.Определение трафика приложений с учетом способов защиты.Создание правил firewall’ов, основанных на трафике приложений.
Принципы построения окружения firewall’а
Существует четыре принципа, которым необходимо следовать:
Простота (Keep It Simple)
Данный принцип говорит о первом и основном, о чем надо помнить при разработки топологии сети, в которой функционирует firewall. Важно принимать наиболее простые решения — более безопасным является то, чем легче управлять. Трудно понимаемые функциональности часто приводят к ошибкам в конфигурации.
Использование устройств по назначению
Использование сетевых устройств для того, для чего они первоначально предназначались, в данном контексте означает, что не следует делать firewall’ы из оборудования, которое не предназначено для использования в качестве firewall’а. Например, роутеры предназначены для роутинга; возможности фильтрования пакетов не являются их исходной целью, и это всегда надо учитывать при разработке окружения firewall’а. Зависимость исключительно от возможности роутера обеспечивать функциональность firewall’а опасна: он может быть легко переконфигурирован. Другим примером являются сетевые коммутаторы (switch): когда они используются для обеспечения функциональности firewall’а вне окружения firewall’а, они чувствительны к атакам, которые могут нарушить функционирование коммуникатора. Во многих случаях гибридные firewall’ы и устройства firewall’ов являются лучшим выбором, потому что они оптимизированы в первую очередь для функционирования в качестве firewall’ов.
Создание обороны вглубь
Оборона вглубь означает создание нескольких уровней защиты в противоположность наличию единственного уровня. Не следует всю защиту обеспечивать исключительно firewall’ом. Там, где может использоваться несколько firewall’ов, они должны использоваться. Там, где роутеры могут быть сконфигурированы для предоставления некоторого управления доступом или фильтрации, это следует сделать. Если ОС сервера может предоставить некоторые возможности firewall’а, это следует применить.
Внимание к внутренним угрозам
Наконец, если уделять внимание только внешним угрозам, то это приводит в тому, что сеть становится открытой для атак изнутри. Хотя это и маловероятно, но следует рассматривать возможность того, что нарушитель может как-то обойти firewall и получить свободу действий для атак внутренних или внешних систем. Следовательно, важные системы, такие как внутренние web или e-mail серверы или финансовые системы, должны быть размещены позади внутренних firewall’ов или DMZ-зон.
В качестве итога заметим, что выражение "всю защиту можно взломать" особенно применимо к построению окружений firewall’а. При развертывании firewall’ов следует помнить о перечисленных выше правилах для определения окружений, но в каждом случае могут иметь место свои собственные требования, возможно, требующие уникальных решений.
Расположение серверов в DMZ-сетях
Где расположить серверы при наличии firewall’ов, зависит от многих факторов, включая количество DMZ, необходимость внешнего и внутреннего доступа к серверам, расположенным в DMZ, интенсивность трафика и чувствительность обрабатываемых данных. Невозможны абсолютно универсальные рекомендации по расположению серверов, но определенные принципы должны учитываться:
Следует изолировать серверы таким образом, чтобы успешные атаки на них не могли причинить ущерба оставшейся части сети, в частности, не следует размещать внешне доступные серверы в защищенной сети.Следует защитить внешне доступные серверы с помощью пограничного роутера с возможностями пакетного фильтра.Следует разместить внутренне доступные серверы в DMZ-сетях, в которых обеспечивается защита как от внешних, так и от внутренних атак, поскольку обычно эти серверы содержат более чувствительные данные и к ним требуется более ограниченный доступ.
Зададим некоторые принципы размещения серверов и систем. Хотя размещение серверов определяется каждой организацией отдельно, исходя из конкретных требований, все усилия должны быть направлены на защиту серверов как от внешних, так и от внутренних угроз, и на изоляцию успешных атак на серверы, чтобы они не влияли на оставшуюся часть сети.
Расположение VPN-серверов
В большинстве случаев наиболее приемлемым является совмещение конечной точки VPN и firewall’а. Как правило, firewall использует IPSec для соединения с удаленными системами и передает незашифрованный трафик firewall’а к внутренней сети. При размещении конечной точки VPN позади firewall’а будет требоваться, чтобы VPN-трафик передавался вовне через firewall в зашифрованном виде; при этом firewall не будет иметь возможность анализировать входящий или исходящий трафик, выполнять управление доступом, создавать логи, сканировать на вирусы и т.п. На рис. 2.4 показана VPN, которая заканчивается firewall’ом, обеспечивая логическое расширение внутренней защищенной сети.
Однако такая топология имеет и свои негативные стороны. Одним из таких недостатков является высокая стоимость. Также, так как VPN- трафик должен быть зашифрован, то это существенно уменьшает производительность шлюза. Выполнение шифрования в аппаратуре существенно увеличивает производительность. Для окружений DMZ дополнительная функциональность, связанная с VPN, может потребовать дополнительных ресурсов, как процессорных, так и памяти.
Реализация набора правил 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 до телефонного сообщения соответствующему персоналу.
Service Leg конфигурация
Одной из конфигураций DMZ-сети является так называемая "Service Leg" конфигурация firewall’а. В этой конфигурации firewall создается с тремя сетевыми интерфейсами. Один сетевой интерфейс соединяется с Интернетом, другой сетевой интерфейс соединяется с внутренней сетью, и третий сетевой интерфейс формирует DMZ-сеть. Такая конфигурация может привести к возрастанию риска для firewall’а при деградации сервиса в течение DoS-атаки, которая будет нацелена на сервисы, расположенные в DMZ-сети. В стандартной конфигурации DMZ-сети DoS-атака для присоединенного к DMZ-ресурса, такого как web-сервер, будет соответствующим образом воздействовать только на этот целевой ресурс. В Service Leg конфигурации DMZ-сети firewall берет на себя основной удар от DoS-атаки, потому что он должен проверять весь сетевой трафик перед тем, как трафик достигнет присоединенного к DMZ-ресурса. Это может влиять на весь трафик организации, если на ее web-сервер выполнена DoS-атака.
Рис. 2.2. Конфигурация Service Leg DMZ
SMTP-серверы
Некоторые firewall’ы могут использоваться для получения e-mail, т.е. установления SMTP-соединений. Наиболее популярная конфигурация включает использование основного firewall’а для:
приема SMTP-соединений;пересылки их выделенному прокси / e-mail серверу, расположенному во внутренней DMZ.
Это необходимо, для того чтобы firewall мог обрабатывать почту, анализируя активное содержимое и вложения.
Если пользователям необходим доступ к e-mail из внешних сетей, например, во время командировок, один из методов защиты SMTP-сервера от прямого внешнего доступа состоит в выполнении SSL-прокси на основном firewall’е. Используя web-браузер, внешние пользователи должны соединиться с основным firewall’ом (он может быть сконфигурирован с использованием дополнительных имен для сокрытия своего имени и иметь открытым только порт для НТТРS, но не для НТТР). Основной firewall будет перенаправлять SSL-соединение внутреннему прокси-серверу, который будет обслуживать e-mail поверх НТТР. В этом случае предотвращается прямой внешний доступ к e-mail серверу, но допускается внешний доступ через firewall. Данный подход также может быть использован и для других типов серверов.
Рис. 2.7. Пример топологии сети с двумя DMZ
На рис. 2.7 показан пример окружения firewall’а с внешней и внутренней DMZ и несколькими серверами. В данном примере VPN-сервер совмещен с основным firewall’ом, и dial-in сервер расположен между пограничным роутером с возможностями пакетного фильтра и основным firewall’ом. Другие внешне доступные серверы также расположены во внешней DMZ. Все остальные внутренние серверы расположены во внутренней DMZ и защищены как от внешних, так и от внутренних угроз.
Сопровождение firewall’а и управление firewall’ом
Для конфигурирования и последующего сопровождения firewall’а используется один из двух возможных механизмов. Первым механизмом является конфигурирование с помощью интерфейса командной строки, который дает возможность администратору конфигурировать firewall посредством вызова различных типов команд в командном режиме. Однако при использовании данной технологии администратор может сделать разного рода ошибки. Основное преимущество конфигурирования в командной строке состоит в том, что опытный администратор может сконфигурировать firewall и реагировать на опасные ситуации гораздо быстрее, чем с использованием графического интерфейса.
Второй (и более общий) механизм состоит в использовании графического интерфейса. Этот интерфейс, как правило, проще. В нем обычно существует возможность уведомлять администратора о необходимости конфигурировать дополнительные системы после истечения определенного времени. Основной проблемой, связанной с графическими интерфейсами, является точность (гранулированность) конфигурирования. Во многих современных firewall’ах существуют опции, которые есть у firewall’а, но они не могут быть сконфигурированы с использованием графического интерфейса. В этом случае должен использоваться интерфейс командной строки.
В обоих случаях следует иметь гарантии, что для всего сетевого трафика, предназначенного для системы управления firewall’ом, выполняются требования безопасности. Для интерфейсов, основанных на web, данная безопасность реализуется использованием неанонимного SSL с последующей аутентификацией пользователя по ID и паролю. Для собственных (не-web) интерфейсов обычно реализуется тот или иной способ шифрования транспорта. То, что все функции управления firewall’ом должны выполняться по безопасным каналам с использованием строгой аутентификации и шифрования, должно быть явно указано в политике.
Создание backup’ов firewall’ов
Создание и сопровождение backup’ов является ключевой точкой в любой политике администрирования firewall’а. Для всех firewall’ов должен выполняться ежедневный backup.
В принципе, на всех firewall’ах всегда должны выполняться полные backup’ы. В инкрементальных backup’ах нет необходимости.
Обычно бывает трудно реализовать централизованную схему управления с доступом к firewall’у. Также предоставление доступа к централизованному серверу backup’а, который обычно расположен за firewall’ом, будет представлять большой риск с точки зрения секретности backup’ов. Следовательно, большинство firewall’ов должно использовать свои собственные устройства архивирования.
Также желательно (но не всегда возможно) использовать firewall’ы, у которых все критичные конфигурационные файлы расположены на CDROM. Для UNIX это является более реальным; основной директорией, требующей доступа по записи, является директория /var все логи обычно хранятся в данной директории. Развертывание firewall’ов, основанных на Windows, с read-only файловыми системами в настоящее время невозможно.
Стратегии восстановления после сбоев firewall’а
Существует много опций для выполнения дублирования и восстановления после сбоев сервисов для окружений firewall’ов. Данный диапазон возможностей включает как использование специально разработанных сетевых коммутаторов, так и применение настраиваемых "пульсирующих" механизмов для проверки доступности первичного firewall’а, чтобы в случае сбоя backup мог взять на себя функции основного.
Сетевые коммутаторы, которые обеспечивают балансировку загрузки и возможности восстановления после сбоя, представляют собой новейшие и наиболее продвинутые решения, доступные на сегодняшний день. В конфигурации восстановления коммутаторы просматривают ответную реакцию от основного firewall’а и перенаправляют весь трафик на запасной firewall в случае сбоя основного. Основным преимуществом такого решения является то, что коммутатор скрывает оба firewall’а за одним и тем же МАС-адресом. Этим обеспечивается возможность бесшовного восстановления после сбоя; во многих случаях установленные через firewall сессии не замечают сбоя основного firewall’а.
Решения, основанные на пульсации, обычно включают back-end или настраиваемый сетевой интерфейс, используемый для оповещения backup-системы в случае сбоя основного firewall’а. Такие системы реализуют надежную технологию восстановления после сбоя. Основной недостаток данного подхода состоит в том, что сессии, установленные к производственному firewall’у, всегда сбрасываются при перенаправлении на backup-ресурсы.
Решение, при котором реализуется метод восстановления после сбоя, часто имеет меньшую стоимость; решение, основанное на восстановлении на основе коммутаторов, является более дорогостоящим.
Тестирование политики firewall’а
Политика firewall’а должна периодически проверяться, по крайней мере, ежеквартально.
Во многих случаях политика firewall’а может быть проверена с использованием одной из двух методик. Первая методика, и наиболее легкая, состоит в получении твердой копии конфигураций firewall’а и анализу ее.
Вторая методика состоит в реальном тестировании конфигурации на самом firewall’е. В этом случае используются инструментальные средства, осуществляющие попытку выполнения операций, которые должны быть запрещены. Это может делаться с использованием как свободно доступных инструментов, так и коммерческих.
Хотя вторая методика выполняет более строгую проверку, должны применяться обе технологии. Цель состоит в гарантировании того, что firewall’ы (так же как и другие устройства, относящиеся к обеспечению безопасности) сконфигурированы точно так, как это должно быть на основании принятой политики. Важно, чтобы сама система firewall’а тестировалась с использованием безопасных средств оценки. Эти средства должны проверять лежащую в основе ОС, а также ПО и конфигурацию firewall’а.
Виртуальные частные сети
Другое возможное использование firewall’ов и окружений firewall’ов состоит в создании VPN. VPN создается поверх существующей сетевой среды и протоколов с использованием дополнительных протоколов, обеспечивающих шифрование и целостность трафика.
VPN применяется для обеспечения безопасных сетевых соединений с использованием сетей, которые не являются доверяемыми. Например, технология VPN все чаще создается для предоставления удаленного доступа пользователя к сетям организации через Интернет. Данное применение пользуется возрастающей популярностью, так как это существенно снижает издержки, связанные с возможностью удаленного доступа, по сравнению с использованием выделенных каналов связи. При использовании технологии VPN организация имеет соединение с Интернетом, которое она может также использовать для удаленного доступа пользователей к сетям и ресурсам организации, расположенных удаленно. Тогда единственное соединение с Интернетом может использоваться для предоставления многих сервисов. Как следствие, данный механизм считается наиболее оптимальным по цене.
Рис. 2.4. Пример совмещения firewall’а и VPN
Технология VPN часто используется для создания безопасных соединений между организациями.
С точки зрения используемого протокола, существует несколько возможных выборов для создания VPN. Наиболее часто используется семейство протоколов IPSec. Другие протоколы VPN: PPTP (Point-to-Point Tunneling Protocol), являющийся стандартом Microsoft, и L2TP (Layer 2 Tunneling Protocol).
Внешне доступные серверы
Внешне доступные НТТР-серверы, а также серверы каталога или DNS-серверы, могут быть размещены во внешней DMZ, т.е. между пограничным роутером с функциями пакетного фильтра и основным firewall’ом. Пограничный роутер может обеспечить некоторое управление доступом и фильтрацию трафика для серверов, а основной firewall — предотвратить создание соединений от серверов к внутренним системам, которые могут устанавливаться, если серверы будут взломаны. В случае большого трафика и сильной загруженности серверов может использоваться высокоскоростной пограничный роутер с несколькими присоединенными DMZ для изолирования серверов в индивидуальных DMZ-сетях. Таким образом, если осуществляется DDoS-атака на некоторый сервер, остаток сети не пострадает.
Внутренние серверы
Внутренне доступные НТТР-серверы, SMTP-серверы и серверы каталога могут быть размещены во внутренней DMZ, т.е. между двумя выделенными firewall’ами, основным и внутренним; при этом внутренний firewall отделяет внутреннюю DMZ от защищенной сети. Размещение этих систем во внутренней DMZ обеспечивает оборону вглубь, защищая как от внешних, так и от внутренних угроз. Если НТТР-прокси используется для исходящего трафика, размещение этих систем во внутренней DMZ обеспечивает большую защиту от внутренних и внешних угроз.
Возможности создания логов firewall’а
Практически все системы firewall’а обеспечивают ту или иную функциональность создания логов. Как обсуждалось ранее, логи в прикладном прокси являются более объемными, чем логи пакетных фильтров или firewall’ов stateful inspection. Причина в том, что прикладные фильтры анализируют большее число уровней модели OSI, чем пакетные фильтры.
Общим примером функциональности создания логов является приложение syslog в UNIX. UNIX syslog предназначен для централизованного создания логов, а также имеет много опций для их проверки и обработки. Данная программа создания логов доступна практически во всех основных ОС, включая Windows NT, 2xxx и все разновидности UNIX и Linux.
После того как логи firewall’а будут переданы централизованному серверу логов, могут использоваться различные пакеты для их обработки. Логи, основанные на syslog, могут также подаваться в качестве входа в пакеты анализа проникновения и использоваться для судебного расследования.
Те firewall’ы, которые не поддерживают интерфейса syslog, должны использовать свою собственную внутреннюю функциональность создания логов. В зависимости от платформы firewall’а, существует много инструментальных пакетов третьих фирм для поддержки и обработки логов.
Возможные подходы к эксплуатации firewall’а
При эксплуатации и определении политики firewall’а следует решить, использовать ли firewall в виде отдельного аппаратно-программного средства (appliance) или в составе ОС. Хотя данное решение в большей степени определяется требованиями организации, должны быть рассмотрены следующие аспекты:
В общем случае, аппаратно-программные firewall’ы являются более безопасными, чем те, которые реализованы в ОС. Аппаратно-программные firewall’ы не имеют уязвимостей, связанных с лежащей в их основе ОС. Они обычно реализуют технологию ASIC (Application-Specific Integrated Circuit); при этом ПО firewall’ов реализовано в виде firmware. Эти firewall’ы обычно более производительные, чем те, что реализованы в ОС.Преимуществом реализации firewall’ов в ОС является их масштабируемость. Если окружение потребует большей производительности, организация может купить более мощную систему, на которой будет выполняться ПО firewall’а. Большинство аппаратно-программных firewall’ов не имеют такой степени гибкости и масштабируемости.Самым большим недостатком реализации firewall’ов в ОС является потенциальное наличие уязвимостей в этой ОС, которые могут нарушить безопасность самого firewall’а. В большинстве случаев, когда коммерческие firewall’ы взламываются, этот взлом происходит из-за уязвимостей лежащей в их основе ОС.
Данное решение должно быть принято на основе цены, а также оценки возможных будущих требований.
VPN и Dial-in серверы
Эти серверы лучше разместить во внешней DMZ, чтобы их трафик проходил в локальную сеть через основной firewall. Одна из возможных конфигураций состоит в совмещении VPN-сервера и firewall’а, чтобы исходящий трафик мог быть зашифрован после того, как он будет отфильтрован, и входящий трафик может быть дешифрован и затем отфильтрован firewall’ом. Dial-in сервер должен быть размещен во внешней DMZ по тем же причинам.
Встраивание firewall’ов в ОС
Другим ключевым фактором успешного управления окружением firewall’а является согласованность платформы. Firewall’ы должны быть реализованы на системах, содержащих встроенные ОС, которые специальным образом урезаны и усилены для приложений безопасности, например, представляют собой так называемый "бастионный хост". Firewall’ы никогда не должны размещаться на системах, которые имеют какие-либо опции, позволяющие проводить инсталляцию.
Конфигурирование ОС firewall’а должно быть основано на принципе оставления минимального множества возможностей. Все ненужные функциональности ОС, особенно компиляторы, редакторы и другие инструментальные средства разработки должны быть удалены до того как firewall начнет функционировать. Все необходимые patches ОС должны быть применены перед инсталляцией компонент firewall’а.
Конфигурирование ОС не должно абсолютно полагаться на модификации, сделанные в процессе инсталляции firewall’а. Программы инсталляции firewall’а основаны на минимально необходимых установках; дополнительные пакеты или модули при инсталляции могут быть не удалены или не запрещены.
Процедура укрепления, используемая при инсталляции, должна основываться на свойствах конкретной ОС, лежащей в основе. Должны быть выполнены следующие действия:
Любые неиспользуемые сетевые протоколы должны быть удалены из ОС, на которой выполняется firewall. Неиспользуемые сетевые протоколы могут потенциально использоваться для получения доступа к firewall’у. Запрещение неиспользуемых протоколов гарантирует, что атаки на firewall, использующие технологии инкапсуляции протокола, не будут эффективны.Любые неиспользуемые сетевые сервисы или приложения должны быть удалены или запрещены. Неиспользуемые приложения часто применяются для атаки на firewall’ы, потому что многие администраторы небрежно относятся к модификации установок по умолчанию для управления доступом firewall’а. Кроме того, неиспользуемые сетевые сервисы и приложения обычно выполняются, используя конфигурации по умолчанию, которые, как правило, намного менее безопасны, чем реальные конфигурации.Любые неиспользуемые пользовательские или системные аккаунты должны быть удалены или запрещены. Данная проблема специфична для каждой ОС, так как все ОС различаются в терминах, в которых представлены аккаунты по умолчанию.Применение всех соответствующих patches ОС также является критичным. Так как patches и hot fixes обычно адресованы для решения проблем, относящихся к безопасности, они должны быть интегрированы в процесс построения firewall’а. Patches всегда должны быть протестированы на непроизводственной системе перед тем, как ставить их на производственную систему.Неиспользуемые физические сетевые интерфейсы должны быть удалены с сервера.
