Происхождение термина неизвестно



Скачать 84.83 Kb.
Дата06.05.2016
Размер84.83 Kb.
История
Происхождение термина – неизвестно

формальное определение -firewall это барьер между “мы” и “они” для произвольных значений “они”. (Steve Bellvin, AT&T)

первый проксирующий firewall – Dave Presotto, Fred Trickey, AT&T (1986-1987)

первый коммерческий – DEC SEAL (1990, Marcus Ranum, Fred Avolio, установлен в Кембридже,

пользователи в Palo Alto отказались, первая продажа 1991, Dupont). Концепция Ранума “firewall без пользователей” (до того в аналогичных целях в DEC использовалась машина с shell доступом). 10,000 строк кода, первый прототип создан за неделю.

первый stateful IP фильтр – Geoff Mulligan (DEC, 1990)

(формирование рынка (Raptor Eagle, ANS Interlock))

FWTK, написан для DARPA по заказу администрации президента, 1993 год

(Firewall'ы на защищенных операционных системах – Harris Cyberguard, Secure Computing Sidewinder)

Gil Shwed и Shlomo Kramer пытаются продать TIS (а потом кому-нибудь еще в US) Firewall-1. Никто не покупает, они создают команию Checkpoint (тут бы вставить их первый уродский логотип).

Первый вариант stateful inspection – практически ничего не делает. Checkpoint делает ставку на производительность, начало психоза с бенчмарками firewall'ов в пакетах в секунду в ущерб безопасности, формирование мифа о “новой технологии”.

Миф о backdoor в Firewall-1: запущен конкурентами, оказался полной ерундой, но в процессе внимательного изучения выясняется, что у них просто руки такие. Продажи государственным организациям в US, однако, заблокированы.

Дальнейшая эксплуатация производительсти как основого критерия оценки. Watchguard, Sonicwall.

Что такое firewall сегодня.


Четыре разных класса устройств, четыре разные задачи, независимая эволюция, разные технологии:


  1. Первичная фильтрация на внешнем периметре – защита DMZ и базовая защита для внутреннего firewall'а. Потомки фильтрующих маршрутизаторов или модули для маршрутизаторов. Ключевые параметры – производительность и обеспечение высокой доступности, базовая поддержка VoIP, устойчивость к DDOS, технологии intrusion prevention.




  1. Firewall для защиты локальной сети – второй уровень защиты. Производительность не имеет значения! Необходимо правильно сегментировать сеть – не бывает (или почти не бывает) нескольких тысяч (и тем более десятков тысяч) рабочих станций с “плоской” универсальной политикой безопасности. Такой firewall нужен на каждый отдел, максимум – сотни компьютеров. Ключевые параметры – способность к полному анализу протоколов, гибкость политик передачи данных и интеграция с внешими фильтрами. Сигнатурный анализ уместен в качестве дополнительного средства, но никак не основного (хотя необходим, например, в антивирусном модуле), поэтому то, что традиционно называется технологиями intrusion prevention, основной функциональностью не является, а строить подобную систему на ip-фильрации просто неразумно. Также следует отметить, что именно для этого класса продуктов имеет особенное значение интеграция в единую систему управления и отчетов.



  1. VPN-концентратор. Выходит за рамки рассмотрения в настоящий момент, вообще говоря специальных технологических причин объединять его с чем-либо из вышеописанного нет.




  1. “Small Office” firewall. Основной параметр – цена. О детских игрушках в другой раз.

Следует обратить внимание, что в этом списке из четырех пунктов нет одного – того, который производят т.н. лидеры рынка: маркетинговой химеры под названием “универсальный firewall”.

Не может быть никакого технического обоснования существованию подобного монстра, который делает все вышеупомянутое, но делает это все плохо.
Миф о проксирующих firewall'ах как устаревшей технологии.
Запущенный компанией Checkpoint в середине 90-х годов в качестве средства продвижения более чем посредственного продукта на рынок, где проксирующие firewall'ы доминировали, миф оказался удивительно популярен, как популярным стало и мнение, что производительность является одним из важнейших параметров для любого firewall'а. К сожалению, ведущие производители проксирующих firewall'ов приложили недостаточно усилий для разоблачения этого мифа (а некоторые – предпочли запрыгнуть в ту же лодку), а специалистов по безопасности мало кто слушает, да они и физически не в состоянии противостоять уровню шума, создаваемому маркетинговой машиной. Желающие могут ознакомиться с детальным опровержением на персональных сайтах таких людей, как Ranum и Avolio, а я остановлюсь на двух деталях, которые считаю главными:
a) пакетные фильтры не в состоянии обеспечить высокий уровень безопасности, потому что интерпретация транзитных данных не обязательно совпадает с интерпретацией данных оконечными узлами на уровне tcp/ip. Почему? Потому что она зависит от реализации. Фрагментация, нумерация пакетов, другая служебная информация в заголовках – все существующие реализации стека tcp/ip

можно описать, как набор performance hacks. Соотвтественно, в машине состояний есть переходы, которые не определены. Было бы интересно увидеть доказанно алгоритмически правильный стек tcp/ip, но на настоящий момент такой реализации нет.


b) пакетные фильтры не в состоянии обеспечить высокий уровень безопасности, потому что интерпретация транзитных данных не обязательно совпадает с интерпретацией данных оконечными узлами на уровне протокола приложения. Почему? Потому, что даже “фильтр уровня приложения” не имеет в себе полной машины состояния протокола. Даже если мы проигнорируем первую проблему и предположим, что у нас есть правильно реконструированный поток tcp/ip. В лучшем случае он имеет ограниченный набор переходов вида “это может следовать за тем” на уровне сигнатур данных, в худшем – просто набор заданных реакций на сигратуры.
Пожалуй, следует упомянуть один продукт, который, пожалуй, максимально приблизился к решению первой проблемы – это пакетный фильтр pf из операционной системы OpenBSD.
Купить или построить – тулкит как инструмент специалиста по безопасности.
Десять лет назад этот вопрос вызывал споры, пять лет назад, казалось бы, рынок окончательно пришел к коробочным решениям; остался ровно один коммерческий firewall, поставляемый с исходными кодами, и то не слишком популярный. о нем позже. Оставшиеся на рынке продукты с открытым кодом практически полностью вытеснены в нижнюю категорию – ранее упомянутые firewallы для малых офисов (причем внутрь лучше не заглядывать во избежание психологической травмы). Причина этого имеет комплексный; одна из них в том, что количество специалистов по безопасности, способных строит решения на основе тулкитов слишком мало, чтобы обеспечить потребности рынка, поэтому спрос на качественные тулкиты низок, хотя и довольно устойчив. Это породило встречную проблему: отсутствие предложения.

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

есть ли в этом необходимость? Я считаю, что ответ - “да” на оба вопроса. Конечно, трудно привлечь требуемые для сложного проекта ресурсы средствами community, но их и нужно значительно меньше, так как модель разработки opensource имеет в этом значительные преимущества, относящиеся к самым затратным моментам – тестированию, аудиту кода и обеспечению качества, и к тому же дает более развитый механизм обратной связи с пользователем. Что касается необходимости, то в технической реализации сетевой политики безопасности есть одна проблема, для которой тулкит является практически единственным решением: это обеспечение алгоритмической прозрачности. То есть при использовании практически любого современного продукта администратор знает, какие данные будут пропущены, а какие - заблокированы, не более чем приблизительно и степень этого приближения зависит от качества документации и доброй воли разработчиков. В случае с использованием пакетных фильтров с некоторым ограниченным знанием протоколов уровня приложения (то есть популярной технологии, известной как stateful packet filtering или deep packet inspection), это приближение вовсе неопределено из-за описанных мной ранее проблем: ни один коммерческий продукт не содержит описания того, как именно работают эти сигнатуры.

Проект OpenFWTK


Начался проект, как развитие TIS Firewall Toolkit, упомянутого ранее, в 1996 году – как раз, когда вышла его последняя версия, 2.1 (правда, еще никто не знал, что она будет последней). В тогда я построил свой первый firewall на его основе, тогда еще с самым минимумом собственных модификаций, для компании Convey Internet Services. Затем я установил еще несколько, параллельно занимаясь разработкой собственных дополнений, пока не попытался вывести продукт на качественно новый уровень – начиная с 1998 года в компании Eltex T.C.. Проблема с лицензией TIS FWTK, запрещающая коммерческое использование имела мало значения, пока я занимался этим, как частное лицо (так или иначе это можно было оформить, как консультации по установке и сопровождению), но встала в полной мере, когда я захотел придать проекту более официальный статус. Поэтому было принято решение постепенно избавляться от кода, принадлежащего TIS, а также одновременно разработать API нового поколения, т к код FWTK меня перестал устраивать, с сохранением обратной совместимости (и по API и по формату конфигурации). Для этого я документировал старый API и переписал его, а для новых компонентов реализовал более высокоуровневые функции. Далее (частично своими силами, частично другими сотрудниками под моим руководством) были переписаны основные компоненты. Результат вошел в состав коммерческого firewall'а “Gadget”, установленного на нескольких коммерческих и государственных предприятиях, включая пивоваренную компанию “Балтика”. Firewall оказался весьма стабилен и практически не требовал обслуживания.

В последствии (после некоторого этапа “внутриутробного” развития в компании ADVA Technologies, купившей Eltex T.C.) я принял решение развивать продукт, как некоммерческий под лицензией BSD и перенес его на Sourceforge.


Немного об идеологии OpenFWTK. В самом начале я сформулировал достаточно жесткие требования к коду и неукоснительно их придерживаюсь. Это значит, что код должен быть не только правилен и безопасен; он также должен быть компактен и понятен, что позволило на настоящий момент остаться в рамках 70,000 строк кода (TIS fwtk при значительно меньшей функциональности состоял примерно из 40,000 строк). Фактически, это те же требования, что были сформулированы при разработке тулкита TIS, разница в том, что соответствие им еще более строгое. Это накладывает определенные ограничения на процесс разработки: использование сторонних библиотек сведено к необходимому минимуму, а импорт кода из других проектов возможен весьма редко, так как соответствуют этим требованиям очень немногие.
Функциональность была значительно расширена; кроме прокси для большего количества протоколов и расширенного синтаксиса конфигурационного файла (макросы объектов доступа, строки продолжения, включение дополнительных файлов конфигурации) была переработана система аутентикации, во-первых, для устранения определенных архитектурных проблем с безопасностью, присутствовавших в старом тулките, а во-вторых для реализации внесеансовой аутентикации для протоколов, не поддерживающих одноразовые пароли. Также был добавлен интерфейс подключения внешних фильтров конента на основе протокола milter (на настоящий момент задействованный в протоколах smtp, pop3, nntp, http и ftp).
Отдельного упоминания заслуживает обработка протокола http: прокси производит полный парсинг и пересборку html-страниц, а также позволяет назначать гибкие политики фильтрации в зависимости от версии http-клиента, что позволяет реализовать функциональность network admission control для этого протокола.
Другие решения
На настоящий момент есть только один продукт со схожей идеологией: Zorp венгерской компании Balabit. Его основное отличие от OpenFWTK то, что он написан на python. Что с одной стороны делает его более гибким – там используется подход “конфигурация – это программа”, то есть обработку любой ситуации можно сделать как угодно сложной, с другой – на мой взгляд, это идет в ущерб удобству и наглядности. OpenFWTK – продукт с открытым кодом и модифицировать его при необходимости немногим сложнее, хотя он и написан на C.
Если же мы рассматриваем не только opensource, то есть с к чему стремиться, по крайней мере по функциональности - продукты Sidewinder и Cyberguard фирмы Secure Computing.
Направления развития
Если начать с самого технически интересного, то это прокси для XML. Для тех, кто не читает мой блог, опишу свое видение в двух словах - XML является основой многих прикладных протоколов и

умение задавать гибкие политики фильтрации и протоколирования – первейшая необходимость.

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

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


Если говорить о самом ближайшем будущем, то это финализация проектируемого протокола инспекции контента (есть определенное количество неочевидных моментов, из-за которых использование существующих протоколов, таких как i-cap и milter не подходит) и вскоре после этого – новый релиз, реализующий как минимум, google safe browsing api. Надеюсь, что это случится до нового года.
Если выбрать наиболее привлекательное для пользователя, то это, вероятно, планы по интеграции в средства управления информацией о безопасности (скорее всего, OSSIM). Подобная интеграция позволит устанавливать сложную корелляцию событий и получать отчеты с привязкой к субъектам политик безопасности, а не подсистемам IT.
Если выбрать самое интересное для разработчиков – это планы реализовать доступ к API тулкита из других языков, в первую очередь это позволит разрабатывать и адаптировать существующие прокси на python, perl, возможно - ocaml, haskell и другие.

1. Tales from The Early Days of The Firewall, Macrus J Ranum, Cyberguard User Conference, 2004, West Palm Beach


База данных защищена авторским правом ©bezogr.ru 2016
обратиться к администрации

    Главная страница