Category: компьютеры

Category was added automatically. Read all entries about "компьютеры".

yo

Правила для Jetico Personal Firewall

NB! Статья написана про JPF v1. JPF v2 во многом отличается от v2, хотя основные идеи там те же.

NB! За консультациями по настройке JPF обращайтесь сюда. Я не консультирую, в особенности по JPF2.

Чуть раньше я уже писал про лучший на мой взгляд файрвол для 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 – полный доступ.

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

JPF Question

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

  • Для программ 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.

permalink Add comment