Avishai Wool Tel Aviv University
Анализ реальной конфигурации показывает, что корпоративные межсетевые экраны часто имеют наборы правил, нарушающие рекомендации по безопасности.
Межсетевые экраны – краеуголный камень корпоративной внутрисетевой безопасности. Однажды компания приобретает межсетевой экран, который системный администратор должен сконфигурировать и в последующем управлять им в соответствии с политикой безопасности согласованной с корпоративными потребностями. Конфигурация – критически важная задача, возможно это самый важный фактор в обеспечении безопасности при помощи межсетевого экрана[1].
Эксперты по сетевой безопасности обычно считают корпоративные межсетевые экраны плохо сконфигурированными, о чем свидетельствует наличие профессионально ориентированных почтовых рассылок, таких как Firewall Wizards (http://honor.icsalabs.com/mailman/listinfo/firewall-wizards). Эта оценка косвенно подтверждается последних вирусных эпидемий, таких как Blaster[2] и Sapphire[3] которые правильно сконфигурированные межсетевые экраны должны были просто блокировать.
Однако не существует количественных исследований, напрямую подтверждающих существование проблемы, т.к. конфигурационные файлы корпоративных межсетевых экранов, или наборы правил, вещь очень важная и, следовательно, тщательно защищаемая.
Четыре года назад я руководил разработкой программного обеспечения Firewall Analyzer (www.algosec.com), которая выросла из проекта Bell Labs[4] в коммерческий продукт[5]. В течении этого времени я имел благоприятную возможность анализировать наборы правил, полученные от различных корпораций. Я сосредоточилсяна наборах правил для межсетевого экрана Check Point Firewall-1, а конкретно на 12 неправильных конфигурациях, которые позволяют получить доступ из-за пределов корпоративной политики сетевой безопасности. По документированной повторяемости ошибок в конфигурациях реальных межсетевых экранов я мог проверить существование корелляции с другими факторами – особенно операционной системой, на которой запущен межсетевой экран, версию МЭ, и оценить сложность набора правил.
Между 2000 и 2001 было проверено 37 наборов правил, собранных среди организаций из телекоммункационной, финансовой, энергетической, автомобильной отраслей, здравоохранения и СМИ, таких как исследовательские лаборатории, академические институты и консалтинговые фирмы по сетевой безопасности.
В таблице 1 приведена основная статистика по наборам правил: количество правил в наборе, количество объектов, определенных в базе данных поддержки правил и число сетевых интерфейсных карт на межсетевом экране.
Таблица 1. Статистические характеристики собранных наборов правил.
Описание свойства |
Минимум |
Максимум |
Среднее |
Количество правил* |
5 |
2671 |
144 |
Количество объектов** |
24 |
5847 |
968 |
Количество интерфейсов*** |
2 |
13 |
4.1 |
* Общее количество правил в наборе, включая правила трансляции адресов (NAT)
** Сетевые объекты (хосты, подсети и их группы), определенные в базе данных поддержки правил.
*** Сетевые интерфейсные карты на МЭ.
Таблица 2 содержит распределение МЭ по трем операционным системам, на которых запущен межсетевой экран: Sun Solaris, Nokia IPSO, и Microsoft Windows NT. Таблица 3 показывает распределение версий Check Point в собранных наборах правил. Версии имеют отношение к теме статье, т.к. производитель вносил некоторые изменения в конфигурацию по умолчанию в версии 4.1, что должно помочь осветить некоторые общие ошибки конфигурации.
Таблица 2. Распределение наборов правил по операционным системам.
Операционная система |
Распределение (%) |
Sun Solaris |
48.7 |
Nokia ISPRO |
35.1 |
Microsoft Windows |
16.2 |
Таблица 3. Распределение наборов правил по версиям ПО.
Firewall-1 |
Распределение (%) |
Версия 3.0 |
|
Версия 4.0 |
|
Версия 4.1 |
|
Версия NG |
Перед тем, как начать делать любые выводы, основанные на этих данных, необходимо сделать предупреждение о значимости найденного. Во-первых, 37 наборов правил это очень маленькая выборка – количество установленных экранов Check Point оценивается в сотни тысяч.
Кроме того, эти наборы правил не случайная выборка. Они получены от организаций готовых платить деньги за аудит их наборов правил внешним компаниям. Т.е. имеются необъективные примеры плохо сконфигурированных межсетевых экранов..
С другой стороны, получение любого числа реальных наборов правил МЭ – редкость. Фактически нет уверенности, что любое количественное исследование по этой тематике дает такой же вклад в исследование этой области.
Администраторы межсетевых экранов интуитивно классифицируют наборы правил как «сложные» или «простые». Необходимо дать количественную оценку этим интуитивным понятиям для точного измерения сложности. Необработанное число правил – очевидный критерий для оценки сложности наборов правил. Однако это число само по себе недостаточное по следующим двум причинам:
Во первых, одно правило МЭ Check Рoint FireWall-1 может иметь список из множества объектов - источников, объектов – назначений и сервисов. Поэтому оценка «реального» числа правил должно требовать подсчета всех объектов этих типов – нудных вычислений, которые имеют приоритет перед интуитивной оценкой. Вместо этого был использован простой метод: суммировалось общее число объектов в базе данных, поддерживающей наборы правил, с количеством правил.
Во вторых , в Check Point FireWall-1 правила применяются одновременно ко всему трафику, проходящему через межсетевой экран от одгого сетевого интерфейса к другому. Число возможных путей между сетевыми интерфейсами в межсетевом экране увеличивается квадратично числу интерфейсов, усложняя задачи администрирования. Точнее, если межсетевой экран имеет N сетевых интерфейсов, число путей через МЭ между различными интерфейсами равно N(N-1)/2. Для учета этого, вычисленное значение по указанной формуле суммировалось с другими значениями.
Так была получена простая, интуитивно-понятная оценка сложности правил:
Сложность = Правила + Объекты + Иф*(Иф – 1)/2 ;
где:
Сложность – оценка сложности набора правил;
Правила – общее число правил в наборе;
Объекты – общее количество сетевых объектов;
Иф – количество интерфейсов на межсетевом экране.
Для количественной оценки качества конфигурации межсетевого экрана необходимо определить, что является ошибкой конфигурации. Как правило это определение субъективно, т.к. приемлемые политики одной компании могут оказаться абсолютно неприемлемы для другой. Тем не менее, материалы данного исследования не показывают, какие компьютеры компании являются настольными, а какие веб-серверами и файл-серверами, т.е. не дают информации о содержании корпоративной политики.
Для обеспечения максимальной объективности были адаптированы некоторые положения внешнего аудита, считались за ошибки только те конфигурации, которые нарушали хорошо известные в индустрии практики и руководства[6]. Так, найденные варианты только грубая оценка, защита описанными межсетевыми экранами может оказаться еще хуже, чем в описываемом случае.
В этом исследовании следующие 12 конфигураций засчитывались как ошибки:
1. Нет правила невидимости. Для защиты межсетевого экрана от несанкционированного доступа в общем случае должно иметься правило невидимости примерно следующего вида: «Для МЭ, любые сервисы – блокировать». Отстутствие такого правила засчитывалось за ошибку конфигурации.
2-4. Неявные правила Check Point. Кроме обычных, написанных пользователем правил пользовательский интерфейс Check Point FireWall – 1 имеет несколько флажков, которые порождают неявные правила. Эти правила управляют обоими службами доменных имен (DNS), отдельно через TCP и UDP и через ICMP. Однако неявные правила имеют очень общий характер, как правило разрешают сервисы все ко всем. Например DNS, один из наиболее часто атакуемых сервисов[7], описанный кратким явным правилом болнн безопасен. Таким же образом с разрешенным ICMP все ко всем, злоумышленник может сканировать внутреннюю сеть, распространяя вирусы типа Nachi/Welchia[8]. Каждый из этих трех возможных неявных правил: DNS-TCP, DNS-UDP и ICMP считаля как одна ошибка.
5. Небезопасное управление межсетевым экраном. Доступ к порту управления межсетевого экрана через небезопасные, нешифрованные и слабо аутентифицирующие протоколы, такие как telnet, ftp или x11 считался за ошибку.
6. Слишком большое число управляющих компьютеров. Межсетевой экран должен управляться с небольшого числа машин. Разрешение управления с более чем 5 компьютеров считалось за ошибку конфигурации. Эта пороговая величина субъективна, однако большинство экспертов согласны с ее величиной.
7. Внешние управляющие компьютеры. За ошибку считалось если компьютер, находящийся вне сетевого периметра мог управлять межсетевым экраном. Более предпочтительно управлять межсетевым экраном из дома изнути, соединяясь с внутренней сетью через VPN.
8. Сервис NetBIOS. NetBIOS это набор служб операционной системы Microsoft Windows, поддерживающий такие сетевые функции как совместное использование файлов и принтеров. Эти часто атакуемые сервисы очень не безопасны.[9] Разрешение прохода любого сервиса NetBIOS через межсетевой экран в любом направлении засчитывалось как ошибка.
9. Сервисы зеркалирования портов (portmapper) и удаленного вызова процедур (Remote Procedure Call, RPC). Демон зеркалирования портов назначает TCP порты для реализации сервиса RPC, механизма Unix, имеющего длинную историю уязвимостей. Среди других сервисов, RPС включает сетевую файловую систему (NFS), которая делает потенциально уязвимыми все файловые системы организации. Разрешение трафика сервиса зеркалирования портов (TCP или UDP на порту 111) засчитывалось за ошибку.
10. Объекты, объединяющие зоны. Сетевые объекты Check Point это именованные наборы IP адресов. Объекты, объединяющие зоны, включают адреса, расположенные более чем с одной стороны межсетевого экрана, например несколько IP адресов из внутренней сети и несколько из внешней. Обратите внимание, для межсетевого экрана, имеющего более двух сетевых интерфейса, каждый из интерфейсов – разные зоны. Объекты, объединяющие зоны, являются причиной многих неприятных последствий при их использовании в правилах межсетевых экранов. Например, когда системный администратор пишет правило, он предпологает, что его объект внутренний или внешний и ожидает соответсвующий эффект. Объекты, объединяющие зоны, ломают эту дихотомию с ужасными результатами.[10][11] Любое использование объектов, объединяющих зоны, считалось ошибкой.
11. Сервис «Все (Any)» во входящих правилах. Разрешение сервиса «Все» для входа в сеть – грубая ошибка, т.к. «Все» включает значительное количество сервисов с большими рисками, включая NetBIOS и RPC. Разрешение такого сервиса считалось ошибкой.
12. Назначение «Все» в исходящих правилах. Т.к. внутренние пользователи обычно не ограничены в доступе в интеренет, исходящие правила, в общем случае, разрешают пункт назначения пакетов как «Все». Тем не менее, межсетевой экран обычно имеет более чем два сетевых интерфейса – более 86% межсетевых экранов в исследуемой выборке. Обычно третий сетевой интерфейс используется для подключения к демилитаризованной зоне (DMZ) – выделенной подсети, в которой расположены корпоративные серверы, видимые извне. При такой конфигурации, пользователи из внутренней подсети имеют свободный доступ с серверам в DMZ, поэтому назначение «Все», по сути, объединяет зоны[12]. Тем не менее, разрешение такого доступа считалось ошибкой.
Пункт 12 вероятно самая субъективная ошибка из учитываемых. Возможно безопасное использование назначения «Все» при внимательном добавлении других правил для ограничения нежелательного доступа. Тем не менее, найденные «destination = Any» в наборах правил межсетевого экрана, как мимнимум, должны получать пометку с предупреждением при аудите.
Рис. 1. Распределение ошибок в конфигурации. Числа показывают номера текстовых описаний ошибок конфигурации.
На рис. 1. показано распределение ошибок в конфигурации обнаруженных в исследуемых данных. Результаты можно охарактеризовать как угнетающие. Много ошибок проявляется в большинстве исследуемых межсетевых экранов, фактически 9 из 12 ошибок проявилось более чем в половине межсетевых экранах.
Даже если не учитывать две наиболее частые ошибки (№ 10 и 12), которые несколько спорны, результаты показывают, что почти 80% межсетевых экранов разрешают любые сервисы во входящих пакетах (№ 11) и небезопасный доступ (№ 5). Это в любом случае большие уязвимости.
Только один из представленных межсетевых экранов имел одиночную ошибку. Все остальные могут быть запросто взломаны неискушенным злоумышленником и глупым вирусом.
В период сбора исходных данных Solaris был старейшей платформой, поддерживающей Check Point, Windows NT встречалась наиболее часто. Nokia IPSO, защищенная версия BSD Unix, была разработана специально для приложений безопасности, таких как межсетевые экраны. Межсетевые экраны на Sun более типичны для больших организации, маленькие предпочитают использовать Nokia и Microsoft.
Рис. 2. Число уязвимостей в зависимости от операционной системы.
Для этого распределения была проанализирована корреляция между операционной системой и количеством ошибок в конфигурации. В межсетевом экране Check Point FireWall – 1 интерфейс администратора и формат записи правил не зависит от операционной системы, поэтому этот анализ может показаться неуместным. Фактически операционная система, сама по себе, не имеет отношения к качеству конфигурации и результат этого исследования ни в коем случае не должен приниматься как рекомендация по использованию той или иной операционной системы.
Однако выбор операционной системы должен отражать некоторые другие факторы, влияющие на качество конфигурации и выражающиеся в появлении корреляции между числом уязвимостей и операционной системой.
К примеру, три платформы четко распределены в ценовом диапазоне: в период сбора данных ПО Check Point Firewall – 1 и соответствующее железо для межсетевого экрана на платформе Sun стоило больше, чем на Nokia, которая стоила дороже, чем система на Windows. Заявленная производительность систем соответствует этому, основанные на Sun системы позиционируются как более предпочтительные для применений с повышенными требованиями к надежности и большим трафиком.
Кажется логичным, что компании, выбравшие более дорогое решение, высокопроизводительную систему, также имеют лучших системных администраторов и лучшее понимание требований сетевой безопасности. Можно выдвинуть априорную гипотезу, что межсетевые экраны, работающие под управлением Sun, должны быть сконфигурированы лучше, чем работающие на Nokia, которые в свою очередь сконфигурированы лучше, чем запущенные на платформе Wundows.
Рисунок 2 показывает, что ситуация абсолютно противоположна. На рисунке видно, что основанные на Sun системы хуже сконфигурированы, чем две другие платформы, несмотря на то, что данных для Windows значительно меньше.
Это не показывает, что системные администраторы на Sun системах менее компетентны, вероятно тут работает другой фактор. В реальной жизни это может быть по другому благодаря тенденции систем на Sun иметь более длинную историю, многих системных администраторов, управляющих ими и, в общем случае, более комплексно.
В течении сбора наборов правил, Check Point сменил три основные версии программного обеспечения (4.0, 4.1 и NG). В начале 2000 старая версия 3.0 все еще использовалась некоторыми компаниями, несмотря на то, что вендор более ее не поддерживал, собранные данные содержали один набор правил для версии 3.0, как показано в табл. 3.
Версия программного обеспечения межсетевого экрана имеет значение для данного исследования, т.к. компания Check Point внесла несколько изменений в конфигурацию по умолчанию с версии 4.1. Изменения должны были помочь исправить некоторые ошибки конфигурации.
Во-первых, значения по умолчанию полей интерфейса управления, управляющие неявными правилами DNS-TCP, DNS-UDP и ICMP были установлены в выключенное значение, тогда как в версиях 4.0 и более ранних они были включены. Если администратор принимал значения по умолчанию, межсетевой экран версии 4.1 не имел трех ошибок (2 – 4).
Во-вторых, пользовательский интерфейс версии 4.1 имел новый мастер политик. Если администратор использовал этот мастер в конфигурацию включалось правило невидимости и правило, сбрасывающее весь NetBIOS трафик, что закрывало минимум 2 ошибки (№ 1 и № 8).
Можно предположить, что версия 4.1 и более поздние имеют меньше ошибок конфигурации, чем 4.0 и более старые. Оптимистично можно надеятся на уменьшение на 5 ошибок между версиями. Фактически рис. 3 показывает уменьшение среднего количества ошибок с 9.63 для версий 3.0/4.0 до 7.17 для версий 4.1/NG.
Рис. 3. Количество ошибок в зависимости от версии межсетевого экрана.
Фактически преимущество оказывается меньше пяти ошибок. Наиболее вероятная причина в том, что выигрыш в меньшем количестве ошибок полуаю только пользователи, устанавливающие межсетевой экран «с нуля». Если пользователь обновляет экран с версии 4.0 до 4.1, он конвертирует весь предыдущий, небезопасный, набор правил.
Оценка сложности конфигурации находится в широких пределах, от 30 до 8521, среднее значение 1121.
Рис. 4. Число ошибок в зависимости от сложности набора правил.
На рис. 4. показано распределение количества ошибок в конфигурации в зависимости от оценки сложности наборов правил. На рисунке хорошо виден пустой правый нижний квадрант, что говорит об отсутствии хороших сложных наборов правил. Правила хорошо сконфигурированных межсетевых экранов (менее, чем 3 ошибки) очень просты, оценка сложности менее 100. Однако маленькие и простые наборы правил не гарантируют хорошую конфигурацию. Рисунок показывает, что экран может быть не правильно сконфигурирован и при маленьком наборе правил: две конфигурации со сложностью менее 100 имеют 6 и более ошибок.
Фактически оценка сложности дает предварительное, но с неплохой точностью, предсказание числа ошибок в конфигурации: линейная регрессия показывает зависимость числа ошибок от сложности конфигурации как:
N = ln(RC) + 1.5
Эта формула описывает зеленую линию на рис. 4.
Из указанного рисунка можно сделать следующие выводы: ограничение сложности наборов правил позволяет сделать конфигурацию межсетевого экрана более безопасной. Вместо соединения с еще одной подсетью главного межсетевого экрана и добавления соответствующих правил и объектов, предочительней установить новый, выделенных межсетевой экран, предназначенный для защиты только этой подсети. Сложные наборы правил, очевидно, слишком сложны для эффективного управления.
Это четко показывает, что корпоративные межсетевые экраны часто неправильно сконфигурированы. Выявлено несколько полезных моментов для улучшения качества наборов правил. Например, более поздняя версия CheckPoint FireWall-1 имеет возможности, позволяющие заметно улучшить безопасность большинства вновь устанавливаемых межсетевых экранов. Более того, низкая сложность наборов правил видится хорошей практикой.
[1] A. Rubin, D. Geer, and M. Ranum, Web Security Sourcebook, Wiley Computer Publishing, 1997.
[2] CERT Coordination Center, “CERT Advisory CA-2003-20: W32/Blaster Worm,” 11 Aug. 2003; www.cert.org/advisories/CA-2003-20.html.
[3] D. Moore et al., “The Spread of the Sapphire/Slammer Worm,” 2003; www.caida.org/outreach/papers/2003/sapphire/sapphire.html.
[4] A. Mayer, A. Wool, and E. Ziskind, “Fang: A Firewall Analysis Engine,” Proc. IEEE Symp. Security and Privacy (S&P 2000), IEEE Press, 2000, pp. 177- 187.
[5] A. Wool, “Architecting the Lumeta Firewall Analyzer,” Proc. 10th Usenix Security Symp., Usenix Assoc., 2001, pp. 85-97.
[6]
W.R. Cheswick and S.M. Bellovin, Firewalls and Internet Security: Repelling
the Wily Hacker, Addison Wesley, 1994.
D.B. Chapman and E.D. Zwicky, Building Internet Firewalls, O’Reilly &
Assoc., 1995.
SANS Institute, “The Twenty Most Critical Internet Security Vulnerabilities,”
v. 4.0, 2003; www.sans.org/top20/.
[7] SANS Institute, “The Twenty Most Critical Internet Security Vulnerabilities,” v. 4.0, 2003; www.sans.org/top20/.
[8] Symantec Security Response, “W32.Welchia.Worm,” Aug. 2003; http://securityresponse.symantec.com/avcenter/venc/data/w32.welchia.worm.html
[9] SANS Institute, “The Twenty Most Critical Internet Security Vulnerabilities,” v. 4.0, 2003; www.sans.org/top20/.
[10] A. Wool, “How Not to Configure Your Firewall: A Field Guide to Common Firewall Misconfigurations,” presentation slides (invited talk), 15th Large Installation Systems Administration Conf. (LISA), Usenix Assoc., 2001.
[11] A. Wool, “The Use and Usability of Direction-Based Filtering in Firewalls,” Computers & Security, in press; available online 2 Apr. 2004; www.sciencedirect.com/science/journal/01674048.
[12] A. Wool, “How Not to Configure Your Firewall: A Field Guide to Common Firewall Misconfigurations,” presentation slides (invited talk), 15th Large Installation Systems Administration Conf. (LISA), Usenix Assoc., 2001.