GQ’s blog

Чуть раньше я уже писал про лучший на мой взгляд файрвол для Windows. И обещал выложить свои правила для него. Что я и делаю. Собственно сами файлы ниже, а вначале некоторые объяснения по поводу того, как именно я представляю себе файрвол в ОС Windows.

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

1. Какие типовые задачи должен позволять решать этот инструмент?
   1. Возможность накладывать ограничения на сетевой траффик на уровне IP и ниже (пакетная фильтрация).
   2. Возможность задавать ограничения на сетевой траффик в приязке к приложениям, этот траффик генерирующим (фильтрация на уровне приложений).
2. Кроме того от файрвола хотелось бы:
   1. Простой формы представления всех правил и настроек.
   2. Возможность протоколирования всех событий (прохождение пакетов, срабатывание правил и т.д.).
   3. Возможность задавать шаблоны правил, которые затем можно легко применять к разным программам.
   4. Возможность задавать “Зоны” - диапазоны IP-адресов, которые затем можно использовать в правилах.
3. Дополнительные возможности, которые может предоставлять файрвол:
   1. Базовые функции IDS (Intrusion Detection System)
   2. Отслеживание windows-специфичных механизмов, которыми могут воспользоваться (и пользуются) вредоносные программы, чтобы получить доступ к сети (hooks, внедрение в код дочернего процесса, скрытый запуск других программ (в первую очередь браузеров) и т.п.)

Фильтрация траффика на уровне приложений не относится к функциям файрвола. Да, файрвол может предоставлять интерфейсы для плагинов, позволяющие плагинам осуществлять такую фильтрацию (кэширование DNS, вырезание банеров и поп-апов из HTTP, проверка антивирусом файлов, загружаемых по тем или иным протоколам), но это не должно быть встроенным в его ядро (кивок в сторону Нортонов, Касперских и им подобных).

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

Если кому интересно, из конкурентов я пробовал как минимум следующие:

• Agnitum Outpost Firewall Pro
• ZoneAlarm Pro
• Sygate Personal Firewall Pro
• Kerio Personal Firewall
• AtGuard
• Norton Personal Firewall
• Tiny Firewall

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

Все программы можно разделить на три класса:

1. Доверенные программы, к которым не надо применять никаких ограничений.
2. Программы, которым разрешено соединяться только с определенным сервисом на определенном сервере.
3. Программы, которым запрещено все.

При этом для программ из первого класса надо иметь возможность задавать ограничение по “Зоне”:

1. Разрешено соединение только с локальным компьютером.
2. Разрешено соединение с компьютерами из домашней сети.
3. Разрешено соединение с компьютерами из локальной сети провайдера.
4. Разрешено соединение со всеми.

Как нетрудно заметить, на самом деле эти ограничения (точнее разрешения) будут вложенными: если вы разрешаем программе подключаться к локальной сети провайдера, то уж к своей домашней сети запрещать не имеет смысла.

Перейдем к программам из 2го класса.

Почему-то во многих файрволах (и JPF с правилами по-умолчанию не исключение) принято так или иначе задавать правила для приложений в виде “Программа The Bat! - это почтовая программа и она должна ходить только на порт 25 и 110″. К чему это приводит? Либо пользователь вынужден переодически тыкать мышкой в всплывающее окно с сообщением, что программа полезла куда-то еще (Особенно часто такое бывает с браузерами, потому что пользователи обычно забывают указать, что помимо 80го порта есть еще https (443), ftp-control (21), прокси (1080, 3128), да и вообще нередко встречаются веб-сервера на экзотических портах не говоря уже о забавном соедиении с ftp-data в пассивном режиме). Забавнее бывает, когда к этому правилу еще прибавляют “а на остальные ей ходить нельзя” и потом долго разбираются с вопросом “А почему у меня не работает IMAP (POP3S, IMAPS, SMTPS - подставьте по вкусу)?”

Но самое забавно впереди: допустим для некоторой почтовой программы мы-таки зададим необходимые ограничения по портам. И что? Это защитит нас от гнусных хакеров (”лишнего” интеллекта программы)? На самом деле не очень. Да, если вышеупомянутый TheBat! все же полезет на вебсайт производителя с целью поинтересоваться своей легальностью (чего он все же не делает), то мы это заметим, но ведь он может поступить хитрее: отправить что-либо через 110й порт на сервере, контролируемом производителем (или злоумышленником, если мы говорим о попытке взлома).

Таким образом я пришел к выводу, что на самом деле в большинстве случаев либо мы доверяем программе и даем ей полную свободу внутри некоторой зоны, либо мы ей не доверяем и разрешаем ходить только на определенный порт определенного сервера (например ходить на сервер разработчика - проверять обновляния).

Что касается программ из 3го класса (”Программы, которым запрещено все”), то очевидно, что это вырожденный случай ограничения по зоне.

Очевидно, что не все программы можно отнести к этим 3м (а точнее теперь уже 2м) классам. Самый очевидный контрпример - отнесение программы к 1му классу, но введение дополнительных правил, которые разрешают отдельные соединения вне расрешенной для программы зоны или, наоборот, запрещающие какие-то соединения внутри (случай, когда можно все, кроме как стучать разработчику).

Чтобы избежать этой неприятной ситуации можно переформулировать введенную классификацию следующим образом:

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

Ура. Теперь можно перейти к описанию собственно моих правил. Хотя нет Вначале еще несколько слов о внутренней логике работы JPF, которая мне показалась не совсем очевидной и заставила разбираться с ним пару дней, прежде чем я понял что к чему.

Несмотря на то, что все правила JPF вынесены в одну таблицу в их обработке есть несколько особенностей. Обработка правил инициируется в трех случаях:

• Взаимодействие процессов (установка хуков, вызов одним процессом другого и т.д.)
• Обработка входящего/исходящего пакета
• Отправка/прием пакета приложением

Если обрабатывается взаимодействие процессов, то JPF заходит из корневой таблицы только в те, в которых существуют правила “Process Attack”.

Если обрабатывается входящий или исходящий пакет, то переход идет только в таблицы с правилами типа “System Protocol” и “System IP” и “Application”. Надо отметить, что Stateful inspection срабатывает не только на пакеты, приходящие в рамках уже установленной сессии, но и на пакеты приходящие на порт, который в данный момент кто-то слушает.
И, наконец, при обработке отправки/приема пакетов приложениями переход выполняется только в таблицы с правилами типа “Application”.

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

Для тех, кто не понял:

Значит алгоритм на псевдоформальном языке.

Пришел пакет

PF:
для каждой таблицы типа нетворк или IP в корневой таблице
{
для каждого правила из таблицы
{
если выполняются все условия правила, то РЕЗУЛЬТАТ:=вердикт правила;
goto AFTER_PF;
}
}
РЕЗУЛЬТАТ:=???(никогда не интересовался какой у джетики вердикт по-умолчанию)
AFTER_PF:
если РЕЗУЛЬТАТ==REJECT отбросить пакет и выйти из обработчика
AF:
для каждой таблицы типа application в корневой таблице
{
для каждого правила из таблицы
{
если выполняются все условия правила, то РЕЗУЛЬТАТ:=вердикт правила;
goto AFTER_AF;
}
}
РЕЗУЛЬТАТ:=???(никогда не интересовался какой у джетики вердикт по-умолчанию)
AFTER_AF:
если РЕЗУЛЬТАТ==REJECT отбросить пакет и выйти из обработчика
передать пакет дальше в стек винды и выйти из обработчика

Теперь наконец-то про мои правила. Хотя нет :)) Про зоны. Дело в том, что в Jetico есть одна фича, которая плохо видна невооруженным взглядом: это файлик settings.xml - из гуевого конфигуратора “Configuration Wizard” можно лишь задать две зоны: “Trusted” и “Blocked” (может я что и путаю, давно им пользовался). А вот если открыть его в текстовом редакторе - возможностей намного больше (ищите в докуметации, если там написано, хотя я не уверен). В частности там можно задать произвольное количество различных зон. У меня это “Blocked Zone” (которая на самом деле пустая, так как у меня нет сетей-недоброжелателей, которые надо было бы блокировать), “Infoline Zone” - зона в которую я выпускаю программы, работающие только в локальной сети Infoline (это UKCable++, FTP-сервер и т.п.) и “Trusted Zone” - то, что находится внутри моей домашней сети (второй компьютер, виртуальные машины VmWare и т.п.). Соответственно имена этих указаны во многих правилах вместо диапазонов.
И вот наконец правила:

Во-первых практически во всех таблицах есть в начале и в конце отключенное правило с вердиктом continue, которое можно использовать в целях отладки.

Таблица Process Attack Table - ничего особенного, точно так же как у авторов JPF просто правило ask в конце, которое добавляет новые правила при необходимости.

Таблица Protocols Table - разрешает ARP и WiFi.

Таблица IP Table - разрешает все для TrustedZone, запрещает все для BlockedZone, для зоны InfolineZone разрешает пинговать себя и для зоны Internet (ну на самом деле такой зоны нет, прото для единообразия так таблица названа) запрещает некоторые атаки и разрешает все что надо для работы. Все правила там прокомментированы вполне пристойно.

Таблица Application Table - в самой таблице заданы только несколько правил для svchost.exe разрешающие DNS и DHCP. В принципе в этой таблице можно размещать и другие правила созданные вручную. А также из этой таблицы вызывается таблица Ask User в конце которой выводится запрос к пользователю (правила сгенерированные этим запросом сохраняются тоже в этой таблице).

В таблице Application Table (и ее подтаблице Ask User) в качестве вердиктов можно использовать следующие таблицы:

• AccessToNetworkOnly - для приложения будет разрешен доступ к сети (и открытие сокетов), но соединяться оно само ни с чем не сможет (даже с локальными сервисами). Зачем это надо: Например приложение PuntoSwitcher устанавливает общесистемный хук. При старте оно также хочет получить доступ к сети (access to network). Мы можем запретить ему это, но тогда все приложения, к которым будет прицеплен установленый пунтосвитчером хук (то есть в данном случае все гуевые приложения), не смогут получить доступ к сети (а то мало ли что за хук он установил). Но мы-то знаем, что он ничего плохого не делает и поэтому просто запретим ему соединяться с другими серверами (да и с локалхостом тоже), но доступ к сети все-таки дадим.
• LocalHostOnly - доступ до локальных адресов.
• TrustedOnly - только до зоны Trusted (например у меня TrustedOnly стоит для svchost.exe, чтобы можно было использовать shared folders внутри домашней сети).
• InfolineOnly - только до локальной сети Инфолайна.
• FullAccess - полный доступ.

Таким образом при попытке приложения получить доступ к сети мы можем сразу указать максимальную для него (приложения) зону доступа из выпадающего меню:

Возвращаясь к введенным ранее классам приложений:

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

На этом на сегодня достаточно. Если есть какие-то вопросы или замечания - пишите в комментариях.

PS. В моих правилах отсутствуют правила для PPPoE, так как PPPoE настраивается модемом. Если у вас он настраивается компьютером, то надо добавить соответствующие правила в таблицу Protocol Table.

Скачать правила для Jetico Personal Firewall.

Файлы из архива распакуйте в C:\Program Files\Jetico\Jetico Personal Firewall\Config

NB! JPF проверяет для бинарников контрольные суммы, поэтому, если у Вас отличная от моей версия винды (у меня XP SP2 Eng), то поправьте правила для svchost.exe в таблице Applications table (DNS и DHCP) - просто выберете в контекстном меню “Редактировать” и задайте в качестве приложения свой svchost.exe.