Заархивировано

Эта тема находится в архиве и закрыта для дальнейших ответов.

Djmanus

Настройка правил трафика в Kerio WinRoute Firewall

Рекомендуемые сообщения

Настройка правил трафика в Kerio WinRoute Firewall 6.x.x

--------------

Тут я хочу поделиться своим опытом использования KWRF 6.x.x

для общего доступа к интернету.

Когда происходит любое IP соединение через машину с KWRF (назовём

её как в программе именем "firewall"), KWRF применяет к нему

по очереди, начиная сверху свои правила трафика (traffic policy),

какое правило подойдёт первым, то и выполняется, если никакое

не подходит, то выполняется последнее, которое из списка удалить

нельзя и смысл его - "а всё остальное запретить".

Каждое правило имеет параметры: название, источник, назначение,

протоколы/порты, действие(мона V /низя X), лог (C/P),

трансляция (нету/NAT/MAP). Как это всё по англицки называется

уж писать не буду.

Итак, создаём:

---------- правило N1 -----------

источник: authorized users (есть такое там понятие)

назначение: internet (ваше соединение, dial, vpn, pppoe или что там ещё)

порты: all

действие: V

лог: C

транслятор: NAT

---------

Смысл этого правила таков - разрешить авторизованным юзверам доступ

в инет с трансляцией NAT и вести лог connection.log, чтобы его потом

можно было импортировать в такие анализаторы, как IAM-WR или

ProxyInspectorWR, чтобы смотреть детальную статистику.

Это правило - основа моего подхода настройки политик доступа.

Теперь представим, что ничего другого мы не добавляем, а используем

только его. Какую же функциональность мы получаем ?

Во-первых, юзвер должен стать авторизованным. К этому есть 3 способа:

1. автологин по ip-адресу (в данном случае подходит)

2. ручной логин через http://адрессервера:4080 или https://адрессервера:4081

не сработает, ибо доступ юзвер->сервер:408x правилом не открыт

3. авто-редирект на авторизацию при наборе любой http-ссылки, это тоже

требует отдельного правила.

Итак, пишем юзверам в KWRF в свойствах автологин с нужных адресов.

Во-вторых, ещё один момент - юзверам придётся у себя писать шлюзом

сервер, как и полагается, а вот DNS указывать не его, а

непосредственно провайдерский.

Итак, мы получаем весьма интересную функциональность - юзверы могут

пользоваться интернетом, но не могут добраться до самого сервера

и запущенные на сервере программы тоже не могут вылезти в инет.

Теперь расширим её.

В KWRF встроен кеширующий DNS ретранслятор, которым мы и

воспользуемся, для этого создадим правило, разрешающее самому серверу

доступ в инет по протоколу DNS. (можно просто создать пользователя с

автологином по адресу "firewall host" и тогда сам сервер получит

доступ в инет не только по протоколу DNS, но полностью по правилу N1)

Специально для DNS:

---------- правило N2 -----------

источник: firewall

назначение: internet

порты: DNS

действие: V

лог: C

транслятор: тут не надо

---------

Небольшой недостаток - DNS-трафик будет считаться на сервер, а не

юзверам, использующим ретранслятор. Впрочем, это трафик весьма

ничтожен. Если же есть желание считать на юзверов, то надо в этом

правиле N2 убрать лог C и создать правило:

---------- правило N2-userDNS -----------

источник: authorized users

назначение: firewall

порты: DNS

действие: V

лог: C

транслятор: тут не надо

---------

но, думаю, с этим никто заморочиваться не будет.

 

Далее. У вас есть локальная сеть, пусть она называется lan, кстати

правила можно с одинаковым успехом создавать и по именам сетей, и по

адресам/диапазонам, группам адресов.

Если сервер должен быть виден в этой сети, как одна из обычных машин,

создаём правило:

---------- правило N3 -----------

источник: firewall, lan

назначение: firewall, lan

порты: all

действие: V

лог: нету

транслятор: нету

---------

Это же правило подразумевает доступ клиентов из этой сети до сервера

по протоколам DNS и WebAdmin(408x- авторизация).

 

Более конкретный пример - на сервере карточка "lan" с адресом

192.168.0.1. В сети "lan" юзвер с адресом 192.168.0.2 пишет у себя

в свойствах сетевого подключения шлюз и днс на адрес 192.168.0.1.

Создаются правила 1,2,3. Либо вместо 2 создаётся юзвер "server"

с автологином с firewall, как я уже писал.

 

Юзвер использует автологин с адреса 192.168.0.2, если ему прописано,

либо вручную набирает http://192.168.0.1:4080, чтобы залогиниться.

 

-------

 

Бывает, что для доступа к интернету используется вспомогательная

сетевая карта, через которую устанавливается vpn(pptp) или pppoe.

Если мы запустим визард конфигурации политик доступа,

то карточка эта попадёт в список локальных карт в правило N3,

что не есть хорошо сами понимаете почему. Поэтому я лично у себя

сделал так - это карту выкидываем из всех правил, но создаём правило

через которое пойдёт наше vpn-соединение к провайдеру для конкретного

адреса.

---------- правило N4 - VPN к провайдеру -----------

источник: firewall

назначение: конкретный адрес, куда устанавливается VPN

порты: PPTP

действие: V

лог: нету

транслятор: нету

---------

 

В KWRF есть уникальная возможность организации автоматического

перехода на страницу логина, пройдя который, юзвер попадает на ту

страничку, на которую хотел, будучи ещё неавторизованным.

Сначала в окне настройки пользователей надо включить режим обязательной

авторизации для все пользователей (вроде бы "require user uthentification"),

иначе весь трафик пойдёт на гостя,

что не есть хорошо, ибо мы организуем учёт по пользователям.

Но даже при включенном требовании редирект происходит только с

http-протокола, остальные же начинают работать сразу и на гостя.

Речь идёт о новом правиле N5:

---------- правило N5 - автоматический авторизатор -----------

источник: ваши сети, где находятся потенциальные клиенты, для нас щас это только "lan"

назначение: internet

порты: http

действие: V

лог: C

транслятор: NAT

---------

Вообще-то лог тут не нужен, т.к. никакой трафик через это правило не

пойдёт. Этим сетям с потенциальными клиентами также должен быть

разрешен доступ до сервера по протоколам DNS и WebAdmin(408x).

Как же это работает ?

Когда потенциальный юзвер набирает у себя некий http адрес в браузере,

сначала от него идёт dns-запрос, который должен быть успешно

отработан, затем идёт соединение на узнаный адрес, KWRF по правилу N5

редиректит его на http://192.168.0.1:4080/?390903279372322332xxxxx...

в ссылке зашифрован адрес, куда он изначально хотел.

Тут он авторизуется и далее уже подпадает под правило N1. Не забудьте,

что оно естественно должно быть выше по списку правила N5, а если

это не так, то уж не забудьте включить лог в N5.

Также в настройках KWRF имя самой файрвольной машины лучше указать по

адресу, любому из локальных, а то запрос на http://server:4080/

Эксплорер не отрабатывает корректно, а Опера пытается лезть на

http://www.server.com:4080/, вот такие они глупые.

 

--------

 

Публичные сервисы. Пусть мы хотим на файрволе поставить некий сервис,

например FTP и IRCD,чтобы они были видны всему инету.

---------- правило N6 - public ftp &... -----------

источник: internet

назначение: firewall

порты: ftp,irc

действие: V

лог: C

транслятор: нету

---------

Замечу, что визард создаёт такое правило, в том числе и для случаев,

когда расшариваемый сервис находится на некой другой машине в DMZ, с использованием

MAP на её адрес, смотрите сами.

Проблема! Но это проблема не KWRF, а известных анализаторов логов IAM

и TI - в трафике, прошедшем через N6 будут поменяны местами входящий и

исходящий счётчики, а пользователь будет guest.

 

------------

 

Пусть мы организуем модемный пул, чтобы на подключенные к серверу

модемы люди могли звонить и юзать с него инет, как и юзверы нашей

локалки.

Включаем "принимать входящие подключения" в виндовозе, настраиваем

количество звонков, через которое модемы снимают трубки через реестр.

Присваиваем этим входящим в виндозе некий пул адресов, например

192.168.5.1-100.

Проблема! (была) бился долго - нашел решение. Чтобы у дозвонившихся на

модем автоматически настраивался адрес DNS (в нашем случае это будет

192.168.0.1 , а может быть и 5.1, но адрес 0.1 на машине всегда

активен) надо на сервере у ВСЕХ локальных сетевых карт написать в

свойствах DNS=192.168.0.1. Можно не волноваться, что это приведёт к

"закольцовыванию" работы DNS на сервере. Всё работает!

Если мы не хотим напрягать этих юзверов необходимостью логина, можно

раздать им статические адреса, настроив в KWRF автологины с них.

В серверных виндовозах юзверам можно легко присвоить адреса,

а в 2к и xp придётся воспользоваться сервисом RAE2.

Правила: 1,(2),

-----специальное правило 3-1 для них---------

источник: dial-in

назначение: firewal

порты: dns, webadmin(4080), webadminssl(4081)

действие: V

лог: нету

транслятор: нету

---------

и 5 с добавленным "dial-in" в список сетей (если надо).

Заметьте, что эти внешние юзверы не имеют доступа до сервера и других

сетей.

---------------

 

Немного об анализаторах логов. Кроме политик трафика, в KWRF ещё есть

детальные политики http (http policy). Если вы используете разрешающие

политики (V), не забудьте проверить, чтобы у них было включено ведение

лога. Это свойство относится к логу connection.log. Другой лог

http.log ведётся в любом случае, но несёт неполную информацию и только

про http-соединения, поэтому мы им не пользуемся.

Конечно, могут быть действительно бесплатные по трафику сайты,

трафик которых можно игнорировать. Также я бы не рекомендовал

встроенный только-HTTP-прокси на порту 3128.

В анализаторах используем режим импорта логов "только connection.log",

иначе http-трафик будет дублирован.

 

--------

 

Ещё пример. Оптимизация отправки почты.

Сейчас почему-то стала актуальна проблема отправки почты.

Невозможно подобрать один единственный smtp-релей в сети,

который бы отправлял письма на любые адреса, с любых адресов и всегда

был в онлайне. Бесплатное решение - использовать свой собственный

СМТП-узел на основе сервера SPECTRAL SMTP SERVER.

Он организует прямую доставку от нас в ящики получателей, а если

этот фокус не проходит, то пробует несколько введённых smtp.

Тут можно забить провайдерские smtp (для нас это mail.astranet.ru и

mail.astrakhan.ru) и любые свободные, типа smtp.yandex.ru или

smtp.newmail.ru (оба требуют указать также авторизацию в виде логина

и пароля любого зарегистрированного пользователя этих почтовиков).

Трафик будет считаться на сервер, но нам это не важно, ибо у всех

нормальных людей исходящий бесплатен.

По умолчанию SPECTRAL принимает соединения на порту 15025. Создаём:

---------- правило N7 -----------

источник: lan, dial-in и все сети жеалющих отправлять почту

назначение: ЛЮБОЕ (Any)

порты: SMTP

действие: V

лог: нет

транслятор: MAP to 192.168.0.1:15025

---------

Теперь конечный пользователь может ни о чем не подозревая писать

у себя в почтовом клиенте любой SMTP-сервер на порту 25, как обычно.

---------

Вот несколько простых примеров настройки traffic policy.

© Dimanus, 2005.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Djmanus у тебя открылся новый талант?! ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

--------часть 2---------

Оказывается, людей интересуют такие вот непонятные вещи, как,

например, "запретить Васе аску". Что ж, я отвечу. Перед правилом N1 создаём

---------- правило N АнтиВАска -----------

источник: юзвер Вася

назначение: internet

порты: icq

действие: X

лог:

транслятор:

---------

Или скажем, "запретить Васе porno.com". Тут создаём правило среди HTTP

POLICY, можно указывать и целые категории со списками блек листов.

Задача-двухходовка - разрешить Васе только yandex. Создаём 2 правила,

первое разрешает Васе яндекс, второе, ниже по списку - запрещает Васе

всё.

 

Однако ж задача "запретить Васе любую порнографию" не столь проста.

Тут мы подходим к понятию о таком сервисе, как онлайновый

категоризатор сайтов. И в KWRF встроен один из таких, называется

ISSOrangeFilter, раньше назывался Cobion Orange Filter.

Сам я им давно не пользовался, но говорят, что его таки недоломали

и совсем недавно он работать перестал. Могу порекомендовать

независимый продукт www.KONTROL.info. А можно на эту же машину поставить

ZONE ALARM SEQURITY SUITE, у меня ничё не конфликтует. В зоне разрешаем приложению

winroute.exe активность. Получается, что WR - низкоуровневый

IP-маршрутизатор, а ZONA - высокоуровневый файрвол с анализом

контента, почтовых вложений, кукисов и прочей белибердой ;o)

Даже 2 встроенных антивируса для трафика этих систем - маккофе и

шекпойнт тоже не конфликтуют.

Есть одна тонкость - маккофе из WR, хотя он только для трафика, но при

своём старте создаёт во временной папке тест-файт eicar.tmp и если на

машине есть другой антивирус, проверяющий файлы на лету, и он этот

файлик тут же стирает, то маккофа не стартует. А шекпойнт из зоны

настройки исключений не имеет, его ~для файлов~ надо выключать целиком

в таком случае. Рекомендую использовать DrWeb, в котором можно

настроить, какие файлы не проверять.

 

to be continued...

в следующем выпуске я расскажу вам, мои юные друзья, где взять

инсталляторы всех упомянутых программ и правильные кряки к ним.

 

© Dimanus, 2005.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

вот и я говорю, поставить аутпост и поепаться лучше с девушкой идти))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Djmanus, а где продолжение? Требую продолжение банкета! :D

Ребят, подскажите мне с настройками. Задача такая. Есть сетка на хренадцать компов. Пользователи заходят в свои локальные учётные записи. Одна рабочая группа, в которую входит и сервер. На сервере так же заведены локальные пользователи с теми же паролями. Необходимо управлять доступом в инет автоматически, в зависимости от дееспособности учётной записи пользователя на сервере. Пользователи импортированы из локальных настроек сервера и настроены на авторизацию через Windows NT/Kerberos 5. Каким образом можно автоматически авторизовать пользователей, но чтобы при отключенности учётной записи пользователи на сервере, он не имел бы доступа в инет? Вообще такое возможно? ОС на сервере Win2003, у пользователей ХР.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты