Главная страница
Навигация по странице:

  • ViPNet Coordinator Linux. Руководство администратора |76 Внимание!

  • Общие принципы назначения виртуальных адресов

  • Без использования межсетевого экрана

  • ViPNet Coordinator Linux. Руководство администратора |77

  • ViPNet Coordinator Linux. Руководство администратора |78

  • ViPNet Coordinator Linux. Руководство администратора |79

  • Диапазон идентификаторов

  • ViPNet Coordinator Linux. Руководство администратора |80

  • Примечание.

  • ViPNet Coordinator Linux. Руководство администратора |81 Настройка правил антиспуфинга

  • ViPNet Coordinator Linux. Руководство администратора |82

  • Настройка правил фильтрации открытых IP-пакетов

  • ViPNet Coordinator Linux. Руководство администратора |83

  • ViPNet Coordinator Linux. Руководство администратора |84

  • Решение задач vipnet linux. vipnet_linux решение задач. Руководство администратора


    Скачать 1.91 Mb.
    НазваниеРуководство администратора
    АнкорРешение задач vipnet linux
    Дата18.04.2022
    Размер1.91 Mb.
    Формат файлаpdf
    Имя файлаvipnet_linux решение задач.pdf
    ТипРуководство
    #482334
    страница7 из 17
    1   2   3   4   5   6   7   8   9   10   ...   17
    Внимание! Менять параметр endvirtualip без крайней необходимости не следует, особенно в сторону увеличения.

    startvirtualiphash
    – служебный параметр.

    ViPNet Coordinator Linux. Руководство администратора
    |
    76
    Внимание! Менять параметр startvirtualiphash без крайней необходимости не следует, за исключением тонкой настройки с целью переназначения виртуальных адресов узлов (см. «
    Ручное переназначение виртуальных адресов узлов
    » на стр. 153).
    Секция [debug]
    Секция
    [debug]
    определяет параметры ведения журнала устранения неполадок управляющего демона. Она содержит следующие параметры:

    debuglevel
    – уровень отладки, число от -1 до 5, по умолчанию 3. Значение параметра -1 отключает ведение журнала.

    debuglogfile
    – идентификатор, определяющий место хранения журнала. Формат данного идентификатора следующий:
    <спецификатор протокола>:<спецификатор
    URL для данного протокола>
    . Подробное описание возможных значений данного параметра приведено ниже. Значение параметра по умолчанию: file:/var/log/iplircfg.debug.log
    , что соответствует записи журнала в указанный файл.
    Общие принципы назначения виртуальных адресов
    Виртуальные адреса используются для сетевых узлов, находящихся за внешним межсетевым экраном. Необходимость использования виртуальных адресов обусловлена тем, что узлы, стоящие за разными межсетевыми экранами, могут иметь одинаковые адреса в своих частных сетях, и при использовании их реальных адресов при обращении к ним возникала бы неоднозначность. Для узлов, не находящихся за внешним межсетевым экраном, виртуальные адреса не используются, но все равно за каждым узлом закреплен свой виртуальный адрес. Исключение составляют Координаторы, работающие в режиме Без использования межсетевого экрана (см. «
    Режимы работы
    ПО ViPNet через межсетевой экран
    » на стр. 27).
    Параметры, необходимые для назначения виртуальных адресов, задаются администратором в секции
    [virtualip]
    (см. «
    Секция [virtualip]
    » на стр. 75).
    Четыре октета, составляющие IP-адрес, используются при назначении виртуальных адресов следующим образом:

    Старший октет всех виртуальных адресов имеет одинаковое значение, соответствующее старшему октету начального виртуального адреса startvirtualip

    ViPNet Coordinator Linux. Руководство администратора
    |
    77

    Два младших октета характеризуют сетевой узел. Они одинаковы для всех виртуальных адресов данного сетевого узла, и различны для виртуальных адресов, принадлежащих разным сетевым узлам. Значения двух младших октетов не превышают соответствующих значений, заданных максимальным виртуальным адресом maxvirtualip

    Второй по старшинству (слева) октет характеризует один из реальных адресов сетевого узла.
    Другими словами, при проходе по сетевым узлам меняется сначала младший октет, затем следующий за ним (второй справа). При проходе по реальным адресам одного сетевого узла меняется второй слева октет. Старший октет в обоих случаях остается неизменным.
    Примечание. Назначение виртуальных адресов для каждого реального IP-адреса узла осуществляется только при наличии у cетевого узла параметра secondaryvirtual= on
    (см. «
    Секция [id]
    » на стр. 56). В противном случае работа с узлом осуществляется только с использованием базового виртуального адреса.
    Виртуальный адрес сетевого узла, в котором второй слева октет равен второму слева октету начального виртуального адреса startvirtualip
    , называется базовым виртуальным адресом virtualip сетевого узла. Базовый виртуальный адрес является точкой отсчета при назначении виртуальных адресов для каждого из реальных адресов узла.
    Остальные виртуальные адреса сетевого узла, характеризующие каждый из реальных адресов узла, называются вторичными виртуальными адресами или для простоты – виртуальными адресами, и указываются в параметре ip через запятую после реального адреса. Один из виртуальных адресов узла может совпадать с базовым виртуальным адресом, что практически всегда будет в случае, если узел имеет один реальный адрес.
    Как уже говорилось выше, текущий адрес доступа к сетевому узлу определяется автоматически и содержится в параметре accessip
    . Если в данный момент узел виден по виртуальному адресу, то его адресом доступа считается либо базовый виртуальный адрес, либо (в случае, когда secondaryvirtual= on
    ) вторичный виртуальный адрес, соответствующий первому в списке реальному.
    Вторичные виртуальные адреса могут использоваться, если нужно обратиться к конкретному реальному адресу данного сетевого узла, который виден по виртуальным адресам, а не к узлу вообще. Такая необходимость может возникнуть, например, если на данном сетевом узле работает приложение, которое ожидает сетевые запросы только на одном из адресов. В таких случаях нужно указывать параметр secondaryvirtual= on
    . В

    ViPNet Coordinator Linux. Руководство администратора
    |
    78
    большинстве случаев для обращения к сетевому узлу достаточно одного виртуального адреса (базового), и указывать параметр secondaryvirtual следует лишь тогда, когда администратор узла четко понимает, для чего это нужно.
    При обновлениях адресных справочников, а также изменениях в списке реальных адресов для какого-либо узла сетевые узлы сохраняют свои виртуальные адреса, а вновь добавленные узлы и реальные IP-адреса получают новые свободные виртуальные адреса
    (с учетом ограничения на максимально возможный адрес, заданного параметром maxvirtualip
    ).

    ViPNet Coordinator Linux. Руководство администратора
    |
    79
    Настройка правил обработки открытых IP-пакетов
    Правила обработки открытых (нешифрованных) IP-пакетов содержатся в файле firewall.conf
    Правила обработки включают в себя правила антиспуфинга, правила фильтрации IP- пакетов и правила трансляции адресов. Помимо правил, в файле firewall.conf содержатся служебные параметры межсетевого экрана.
    Файл firewall.conf состоит из следующих секций:

    [antispoof]
    – правила антиспуфинга;

    [local]
    – правила фильтрации локальных IP-пакетов;

    [broadcast]
    – правила фильтрации широковещательных IP-пакетов;

    [forward]
    – правила фильтрации транзитных IP-пакетов;

    [tunnel]
    – правила фильтрации туннелируемых IP-пакетов;

    [nat]
    – правила трансляции адресов;

    [settings]
    – служебные параметры межсетевого экрана.
    В качестве значений некоторых параметров в файле firewall.conf могут быть указаны следующие выражения:

    Диапазон адресов – два IP-адреса, разделенные дефисом. При задании диапазона второй адрес (конец диапазона) должен быть больше, чем первый адрес (начало диапазона). Диапазон адресов включает в себя все адреса, лежащие между началом и концом диапазона, а также начало и конец диапазона.
    Например: 192.168.1.1-192.168.1.10.

    Диапазон идентификаторов – два 32-битных идентификатора сетевых узлов, разделенные дефисом. При задании диапазона второй идентификатор (конец диапазона) должен быть больше, чем первый идентификатор (начало диапазона).
    Диапазон идентификаторов включает в себя все идентификаторы, лежащие между началом и концом диапазона, а также начало и конец диапазона.

    ViPNet Coordinator Linux. Руководство администратора
    |
    80
    Идентификаторы сетевых узлов записываются в шестнадцатеричном формате с префиксом
    0x
    . Регистр букв A-F может быть любым, нули после префикса до первой значащей цифры могут быть опущены.
    Например: 0x10e10000-0x10e100FF.
    Примечание. Диапазон идентификаторов можно указывать только в правилах фильтрации туннелируемых пакетов.

    Маска адресов – сетевой адрес в формате CIDR (Classless Internet Domain Routing).
    Маска адресов состоит из адреса подсети в формате обычного IP-адреса и числа старших битов в маске подсети, которые равны 1. Адрес подсети и число битов разделяются символом «/» (прямой слеш).
    Например: 192.168.1.0/24 (сеть с адресом 192.168.1.0 и маской подсети
    255.255.255.0).

    Маска идентификаторов – идентификатор сетевого узла в формате, аналогичном
    CIDR. Маска идентификаторов состоит из 32-битного идентификатора ViPNet в шестнадцатеричном формате и числа старших битов в маске, которые равны 1.
    Идентификатор и число битов разделяются символом «/» (прямой слеш). Маска идентификаторов по смыслу аналогична маске адресов.
    Например: 0x10e10000/16 (узлы с идентификаторами, у которых старшие 16 бит равны 4321 (0x10e1), т.е. все узлы, входящие в сеть ViPNet с номером 4321).
    Примечание. Маску идентификаторов можно указывать только в правилах фильтрации туннелируемых пакетов.

    Диапазон портов – два номера портов (числа от 1 до 65535), разделенные дефисом.
    При задании диапазона второй номер (конец диапазона) должен быть больше, чем первый номер (начало диапазона). Диапазон портов включает в себя все порты, лежащие между началом и концом диапазона, а также начало и конец диапазона.
    Например: 1024-65535.
    Далее подробно описываются секции файла firewall.conf
    , а также синтаксис правил фильтрации пакетов и правил трансляции адресов.

    ViPNet Coordinator Linux. Руководство администратора
    |
    81
    Настройка правил антиспуфинга
    Правила антиспуфинга позволяют задать для каждого интерфейса список IP-адресов, пакеты от которых допустимы на данном интерфейсе. При этом пакеты, которые не попадают в допустимый список, будут блокироваться. Кроме того, если на какой-либо интерфейс будут приходить пакеты с адресов, которые указаны как допустимые для другого интерфейса, то такие пакеты также будут блокироваться. Как видно из названия, основная задача антиспуфинга – это защита от так называемого «спуфинга», одного из видов сетевых атак, основанного на подделке IP-адреса. При спуфинге злоумышленник посылает какому-либо компьютеру пакет, в котором в качестве адреса отправителя указан не его собственный адрес, а какой-либо другой, который известен данному компьютеру. Например, таким образом можно послать пакет из Интернета на шлюз, задав в качестве адреса отправителя адрес частной внутренней сети, которая также подключена к данному шлюзу, при этом злоумышленник может получить доступ к какому-либо сервису, доступ к которому разрешен только из внутренней сети. Правила антиспуфинга позволяют исключить такую возможность.
    Параметры антиспуфинга задаются в секции
    [antispoof]
    файла firewall.conf
    Синтаксис этой секции такой же, как синтаксис файлов iplir.conf и iplir.conf-
    <интерфейс>
    (см. «
    Общие принципы настройки
    » на стр. 54).
    Секция
    [antispoof]
    содержит следующие параметры:

    antispoof
    – включение/отключение механизма антиспуфинга. Этот параметр может принимать значение yes или no.
    По умолчанию значение параметра no

    Параметры с именами, совпадающими с именами сетевых интерфейсов. Значением каждого параметра является список адресов, допустимых на данном интерфейсе.
    Список адресов может состоять из единичных адресов, диапазонов адресов, масок адресов и ключевых слов, указанных через запятую. Все адреса в списке должны принадлежать подсетям, подключенным к данному интерфейсу. В списке адресов можно указывать следующие ключевые слова: o anypublic
    – означает все адреса, допустимые в Интернете, т.е. все адреса, кроме выделенных для специальных целей: для локального сетевого интерфейса
    (127.0.0.0/8) и для частных сетей (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16); o subnet
    – означает всю подсеть, к которой принадлежит данный интерфейс, исходя из его адреса и маски подсети.
    Если антиспуфинг включен, то при каждом старте управляющего демона или изменении параметров сети производится автоматическое формирование списка адресов, заданного ключевым словом subnet

    ViPNet Coordinator Linux. Руководство администратора
    |
    82
    В секции антиспуфинга обязательно должны быть перечислены все сетевые интерфейсы, кроме локального (loopback). Локальный интерфейс не охватывается никакими правилами обработки пакетов, и на нем всегда пропускаются любые пакеты. Кроме того, следует отметить, что пакеты с адресов отправителя, лежащих в диапазоне 127.0.0.0/8, блокируются на всех интерфейсах, обрабатываемых ПО ViPNet, независимо от настроек антиспуфинга, поскольку таково требование стандартов.
    При старте управляющего демона проверяется, включен ли антиспуфинг, и если он включен, проверяется наличие в секции
    [antispoof]
    всех интерфейсов, известных управляющему демону. Отсутствующие интерфейсы автоматически добавляются в секцию со значением subnet
    Пример секции антиспуфинга:
    [antispoof]
    antispoof= yes eth0= anypublic eth1= 192.168.1.0/24
    В данном примере антиспуфинг включен и будет работать следующим образом:

    на интерфейс eth0
    могут приходить пакеты со всех адресов, кроме частных
    (предполагается, что интерфейс подключен к Интернету);

    на интерфейс eth1
    могут приходить пакеты с адресов от 192.168.1.1 до 192.168.1.255
    (предполагается, что интерфейс подключен к локальной сети).
    Если в данном примере на интерфейс eth0
    из Интернета придет пакет с адресом отправителя из сети 192.168.1.0/24 либо 192.168.201.0/24, то он будет блокирован. Таким образом, обеспечивается надежная защита от спуфинга.
    Настройка правил фильтрации открытых IP-пакетов
    Пакеты, прошедшие через механизм антиспуфинга, попадают на обработку правилами фильтрации открытых пакетов. Правила фильтрации открытых IP-пакетов задаются в секциях
    [local]
    ,
    [broadcast]
    ,
    [tunnel]
    и
    [forward]
    файла firewall.conf
    В секции
    [local]
    задаются правила фильтрации локальных пакетов – пакетов, у которых отправителем либо получателем является данный сетевой узел.
    В секции
    [broadcast]
    задаются правила фильтрации широковещательных пакетов.

    ViPNet Coordinator Linux. Руководство администратора
    |
    83
    Наличие секций
    [local]
    и
    [broadcast]
    обязательно. При старте управляющего демона проверяется наличие данных секций в файле конфигурации. Если какой-либо из этих секций нет, то она автоматически добавляется в файл firewall.conf с правилами по умолчанию (см. «
    Правила фильтрации открытых IP-пакетов по умолчанию
    » на стр. 90).
    В секции
    [forward]
    задаются правила фильтрации транзитных пакетов – пакетов, которые только проходят через данный сетевой узел на пути от отправителя к получателю. По умолчанию в файле firewall.conf присутствует пустая секция
    [forward]
    . Для возможности прохождения транзитных пакетов через узел необходимо, чтобы их прохождение было либо явно разрешено правилами в секции
    [forward]
    , либо соответствующие интерфейсы находились в режимах, позволяющих пропускать пакеты: интерфейс, на который приходят транзитные пакеты – в режиме 4, а интерфейс, с которого они уходят – в режиме 3 или 4. Если используются другие режимы, то нужно обязательно задать разрешающее правило в секции
    [forward]
    . Это относится также к случаю, когда используется трансляция адресов, более подробно настройка такой конфигурации описывается ниже.
    В секции
    [tunnel]
    задаются правила фильтрации туннелируемых пакетов – пакетов, передаваемых между ресурсами, туннелируемыми данным узлом (Координатором), и защищенными узлами сети ViPNet. Наличие секции
    [tunnel]
    в файле конфигурации обязательно. При старте управляющего демона проверяется наличие данной секции. Если этой секции нет, то она автоматически добавляется в файл firewall.conf с правилом по умолчанию, которое разрешает трафик между всеми туннелируемыми ресурсами и всеми защищенными узлами, с которыми связан данный узел (см. «
    Правила фильтрации открытых IP-пакетов по умолчанию
    » на стр. 90).
    В предыдущих версиях ViPNet Coordinator Linux для пропуска туннелируемого трафика необходимо было задать в секции
    [local]
    разрешающие правила открытой сети. Для автоматического создания этих правил использовался параметр autopasstunnels в секции
    [misc]
    файла iplir.conf
    . В текущей версии этот параметр не поддерживается, а правила для туннелируемого трафика задаются в секции
    [tunnel]
    . При переходе на текущую версию параметр autopasstunnels автоматически удаляется из секции
    [misc]
    файла iplir.conf
    , а в файл firewall.conf добавляется секция
    [tunnel]
    с правилом по умолчанию. Уведомления о произведенных изменениях конфигурационных файлов выводятся в системный журнал.
    Обработка IP-протоколов TCP/UDP/ICMP осуществляется на основании анализа различных параметров пакетов. С помощью правил фильтрации можно контролировать протокол, адрес и порт отправителя, адрес и порт получателя, направление установления соединения. Применение фильтрации пакетов по направлению установления соединения позволяет ограничить прохождение пакетов рамками установленных соединений: пропускать только запросы, инициализирующие соединения в заданном направлении, а также ответы на них, и запрещать запросы, инициализирующие соединения в обратном направлении.

    ViPNet Coordinator Linux. Руководство администратора
    |
    84
    Для обработки IP-протоколов, отличных от TCP/UDP/ICMP, создаются виртуальные соединения, основанные на IP-адресах и номере протокола. Таким образом, достаточно указывать разрешающее правило только для запроса, инициализирующего данное соединение, ответы будут приниматься автоматически (если они приходят с того же IP- адреса, на который отсылался запрос, и по тому же протоколу).
    Каждая из перечисленных секций может содержать одно или несколько правил фильтрации. Синтаксис правил фильтрации одинаков для всех секций.
    Каждое правило описывается параметром rule
    , его значение состоит из следующих компонентов: rule= <управляющий компонент> <условие> <расписание> <действие>
    или rule= <управляющий компонент> <действие> <условие> <расписание>
    Управляющий компонент должен указываться в самом начале правила, расписание должно указываться следом за условием.
    Каждый из компонентов правила, в свою очередь, состоит из частей, которые называются лексемами.
    1   2   3   4   5   6   7   8   9   10   ...   17


    написать администратору сайта