Перейти к содержанию

Фильтрафия и кеширования данных из web#

Настройка веб-прокси#

Настройка поведения посредника производится посредством отдачи поддерживаемых им команд через интерфейс командной строки либо через графический веб-интерфейс системы Numa Edge. Перечень поддерживаемых команд, их параметры и задаваемое ими поведение прокси рассмотрены ниже.

Примеры настройки фильтрации#

На рисунке показана схема сети, на которой основаны приведённые ниже примеры. Предположим следующее:

  • устройства из внутренней сети компании пользуются ресурсами Интернет через систему Numa Edge;
  • фильтрация и кэширование веб-содержимого обеспечиваются веб-прокси, входящим в состав системы Numa Edge;
  • веб-прокси не запущен, его конфигурация пуста.

Примеры сквозные, то есть учитывают друг друга. В самом первом из них настраивается привязка прокси к интерфейсу с адресом 192.168.1.254, после чего его (прокси) можно будет запустить (что и происходит по команде commit).

Схема-сети-для-примеров

Схема сети для примеров

Настройка NAT#

В приведенной выше схеме видно, что Numa Edge будет использоваться на границе сети, поэтому необходимо настроить двунаправленное преобразование сетевых адресов (NAT masquerade). Помимо этого, вначале будет настроен прокси в "прозрачном" режиме и для его работы необходимо будет настроить перенаправление портов (DNAT) http и https на порты прокси 3128 и 3129, соответственно. Для работы прокси в "непрозрачном" режиме использование DNAT не требуется.

Настройка NAT для перенаправления HTTPS трафика на прокси сервер.#

Пример - Настройка правила 10 для IPv4 NAT#
  1. Создаем правило 10 для IPv4 NAT: 
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 10
  2. Указываем, что данное правило будет использоваться для преобразования сетевого адреса и порта получателя: 
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 10 type 'destination'
  3. Правило будет работать с пакетами, приходящими на интерфейс локальной сети (eth2): 
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 10 inbound-interface 'eth2'
  4. Указываем адрес, на который будут перенаправляться пакеты: 
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 10 inside-address address '192.168.1.254'
  5. Данное правило будет работать для протокола TCP. Это необходимый параметр для того, чтобы указать порт, на который будет перенаправляться трафик: 
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 10 protocol 'tcp'
  6. Перенаправляем HTTPS-трафик: 
    1
2
    [edit]
admin@edge# set service nat ipv4 rule 10 destination port 'https'
  7. На порт 3129, который слушает прокси сервер: 
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 10 inside-address port '3129'
  8. Применяем текущие настройки: 
    1
2
    [edit]
admin@edge#commit
  9. Просмотр настроенного правила для NAT: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
    [edit]
admin@edge# show service nat ipv4 rule 10
   destination {
      port https
   }
   inbound-interface eth2
   inside-address {
      address 192.168.1.254
      port 3129
   }
   protocol tcp
   type destination

Настройка NAT для перенаправления HTTP трафика на прокси сервер.#

Пример - Настройка правила 20 для IPv4 NAT#
  1. Создаем правило 20 для IPv4 NAT: 
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 20
  2. Указываем, что данное будет использоваться для преобразования сетевого адреса и порта получателя: 
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 20 type 'destination'
  3. Правило будет работать с пакетами, приходящими на интерфейс локальной сети (eth2): 
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 20 inbound-interface 'eth2'
  4. Указываем адрес, на который будут перенаправляться пакеты: 
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 20 inside-address address '192.168.1.254'
  5. Данное правило будет работать для протокола TCP. Это необходимый параметр для того, чтобы указать порт, на который будет перенаправляться трафик: 
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 20 protocol 'tcp'
  6. Перенаправляем HTTP-трафик:
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 20 destination port 'http'
  7. На порт 3128, который слушает прокси сервер: 
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 20 inside-address port '3128'
  8. Применяем текущие настройки: 
    1
2
    [edit]
admin@edge#commit
  9. Просмотр настроенного правила для NAT: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
    [edit]
admin@edge# show service nat ipv4 rule 20
   destination {
      port http
   }
   inbound-interface eth2
   inside-address {
      address 192.168.1.254
      port 3128
   }
   protocol tcp
   type destination

Настройка NAT для маскировки адресов локальной сети#

Пример - Настройка правила 30 для IPv4 NAT#
  1. Создаем правило 30 для IPv4 NAT: 
    1
2
    [edit]
admin@edge# set service nat ipv4 rule 30
  2. Указываем, что данное будет использоваться для двунаправленного преобразования сетевых адресов и портов: 
    1
2
    [edit]
admin@edge# set service nat ipv4 rule 30 type 'masquerade'
  3. Правило будет работать с пакетами, уходящими с WAN интерфейса (eth1): 
    1
2
    [edit]
admin@edge# set service nat ipv4 rule 30 outbound-interface 'eth1'
  4. Применяем текущие настройки: 
    1
2
    [edit]
admin@edge# commit
  5. Просмотр настроенного правила для NAT: 
    1
2
3
4
    [edit]
admin@edge# show service nat ipv4 rule 30
   outbound-interface eth1
   type masquerade

Настройка системного DNS сервера и службы кеширующего DNS#

При установлении соединения с веб-сервером прокси-сервер получает информацию о доменном имени в заголовке "Host" протокола HTTP, либо поле SNI протокола TLS. Далее, прокси сервер самостоятельно получает значение IP адреса, соответствующее данному доменному имени, путем обращения с DNS-серверу. Ввиду этого необходимым требованием для корректной работы прокси-сервера является наличие настроенного системного DNS сервера. Также по соображениям безопасности и во исполнение требований RFC 2616 секции 14.23 значение IP адреса назначения HTTP/HTTPS пакета должно соответствовать заголовку Host/полю SNI. В случае их несовпадения, прокси-сервер будет фиксировать в системном журнале предупреждение о данном несоответствии. Далее, в зависимости от значения атрибута service webproxy host-verify-policy:

  • strict (по умолчанию) – соединение будет прервано, клиенту будет отправлен HTTP ответ с кодом 409;
  • warning – соединение будет продолжено.

Во избежание данного поведения рекомендуется использовать либо общий кеширующий DNS сервер между клиентами и прокси-сервером, либо настроить на Numa Edge кеширующий DNS сервер. В этом примере производится настройка системного DNS сервера.

Пример - Настройка системного DNS сервера#
  1. В качестве системного DNS сервера укажем IP-адрес Яндекс DNS: 
    1
2
    [edit]
admin@edge# set system dns name-server 77.88.8.8
  2. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  3. Просмотр получившейся конфигурации:
    1
2
3
4
    [edit]
admin@edge# show system dns  
  name-server 77.88.8.8 { 
  }

Теперь необходимо настроить службу кеширующего DNS, который будет общаться к вышестоящему DNS серверу и кешировать ответы.

Пример - Настройка службы кеширующего DNS#
  1. В качестве IP адреса, который будет слушать кеширующий DNS укажем адрес 192.168.1.254: 
    1
2
    [edit]
admin@edge# set service dns forwarding listen-on address 192.168.1.254
  2. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  3. Просмотр получившейся конфигурации:
    1
2
3
4
5
6
7
    [edit]
admin@edge# show service dns  
  forwarding {
      listen-on {
          address 192.168.1.254
      }
  }

Блокировка сайтов без подмены сертификата#

Данный пример описывает минимальные настройки для работы прокси сервера. Приводится конфигурация, которая позволяет блокировать доступ к домену vk.com, при открытии сайта через протокол HTTPS.

Пример - Запрет доступа к отдельным адресам#
  1. Включение ожидания запросов на интерфейсе с адресом 192.168.1.254: 
    1
2
    [edit]
admin@edge# set service webproxy listen-address 192.168.1.254
  2. Включение поддержки фильтрации HTTPS-трафика: 
    1
2
    [edit]
admin@edge# set service webproxy listen-address 192.168.1.254 enable-ssl
  3. Блокировка доступа к домену vk.com с помощью анализа поля SNI в сообщении Client Hello: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering ssl block-server name vk.com
  4. Применяем текущие настройки: 
    1
2
    [edit]
admin@edge# commit
  5. Просмотр минимальной настройки прокси сервера: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
    [edit]
admin@edge# show service webproxy 
   listen-address 192.168.1.254 {
       enable-ssl
   }
   url-filtering {
       ssl {
           block-server {
               name vk.com
           }
       }
   }
[edit]
admin@edge#

Создание удостоверяющего центра#

Создание удостоверяющего центра необходимо для генерации подменных сертификатов, при разрыве клиентского SSL-соединения. В этом примере создается УЦ, который генерирует RSA сертификаты с длинной ключа 1024 байта.

Пример - Создание УЦ для генерации подменных сертификатов#
  1. Создание узла конфигурации удостоверяющего центра: 
    1
2
    [edit]
admin@edge# set pki ca WEB_PROXY_CA
  2. Задание размера ключа, который будет использоваться в качестве ключевой пары для сертификата УЦ, и всех подписанным им сертификатов: 
    1
2
    [edit]
admin@edge# set pki ca WEB_PROXY_CA key-size 1024
  3. В качестве типа ключа используется RSA:
    1
2
    [edit]
admin@edge# set pki ca WEB_PROXY_CA key-type rsa
  4. Срок действия сертификата удостоверяющего центра задается равным 5 годам: 
    1
2
    [edit]
admin@edge# set pki ca WEB_PROXY_CA expiration 1826
  5. Для сертификата УЦ задается значение Common Name, указывающее его принадлежность: 
    1
2
    [edit]
admin@edge# set pki ca WEB_PROXY_CA cn "CA for WEB Proxy"
  6. Применение конфигурации: 
    1
2
    [edit]
admin@edge# commit
  7. Просмотр примененной конфигурации: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
    [edit]
admin@edge# show pki ca WEB_PROXY_CA 
  cn "CA for WEB Proxy"
  expires-on "Mon Jul  5 11:04:23 2027"
  key-size 1024
  key-type rsa
  last-update "Tue Jul  5 11:04:23 2022"
  next-update "Mon Jul  5 11:04:23 2027"
[edit]
admin@edge#

  8. Далее данный сертификат необходимо выгрузить из Numa Edge командой операционного режима:

  9. Выход из конфигурационного режима в операционный: 

    1
2
    [edit]
admin@edge# exit

  10. Экспорт сертификата УЦ в домашний каталог пользователя admin. Так же поддерживается возможность экспорта на съемный носитель (без указания атрибута to), либо экспорт на удаленные узлы, используя протоколы SCP, FTP и TFTP: 
    1
2
3
4
    admin@edge:~$ pki export certificate WEB_PROXY_CA to /home/admin/
Производится экспорт сертификата WEB_PROXY_CA в /home/admin/WEB_PROXY_CA.tgz
Экспортируется сертификат WEB_PROXY_CA
admin@edge-no-dm:~$

Сертификат будет экспортирован в архив, который будет необходимо распаковать и добавить в список доверенных УЦ на клиентских устройствах.

Включение подмены сертификатов для прокси-сервера#

Данный пример описывает настройку прокси сервера для перехвата HTTPS соединений с последующей подменой сертификата веб сайта. Для этого необходимо описать домены, соединения к которым должно быть перехвачено. Далее необходимо указать сертификат УЦ, который будет генерировать подменные сертификаты веб-сайтов.

Поскольку технология перехвата соединений включает в себя установку TLS соединения с требуемым веб-сервером со стороны Numa Edge, то на него необходимо импортировать корневые сертификаты доверенных УЦ. Обратите внимание, что если в процессе эксплуатации необходимо будет удалить один из корневых сертификатов УЦ, то после этого необходимо будет запустить службу webproxy, поскольку она кеширует сертификаты во внутреннем хранилище.

Пример - Включение функционала с подменой сертификатов#
  1. Переход в конфигурационный режим: 
    1
    admin@edge-no-dm:~$ configure
  2. Регулярное выражение обозначающее все возможные домены, где символ "." описывает любой символ, а символ "*" – любое количество повторений: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering ssl bump-server regex ".*":
  3. В качестве УЦ, который будет генерировать подменяемые сертификаты указывается ранее созданный УЦ: 
    1
2
    [edit]
admin@edge# set service webproxy ssl x509-cert WEB_PROXY_CA
  4. Применение конфигурации: 
    1
2
    [edit]
admin@edge# commit

Примечание

Обратите внимание, что действия ssl bump-server и ssl block-server могут применяться одновременно, при этом блокировка является более приоритетным действием. В данном примере блокировка домена vk.com продолжает работать, несмотря на включение подмены сертификатов для всех доменов.

Блокировка отдельных адресов (URL)#

Команды примера ниже при помощи фильтра local-block явно указывают отдельные адреса (вне категорий), запросы к которым будут блокироваться.

Пример - Запрет доступа к отдельным адресам#
  1. Запрет доступа к веб-сайту YouTube:
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard local-block youtube.com
  2. Запрет доступа к веб-сайту Facebook: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard local-block facebook.com
  3. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  4. Просмотр текущей конфигурации веб-прокси в этом контексте: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
    [edit]
admin@edge# show service webproxy  
  listen-address 192.168.1.254 { 
      enable-ssl 
  } 
  ssl { 
      x509-cert WEB_PROXY_CA 
  } 
  url-filtering { 
      squidguard { 
          local-block youtube.com 
          local-block facebook.com 
      } 
      ssl { 
          block-server { 
              name vk.com 
          } 
          bump-server { 
              regex ".*" 
          } 
      } 
  } 
[edit]
  5. Запрет доступа к веб-сайту YouTube: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard local-block youtube.com

Проверка работы фильтров#

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

Просмотреть содержимое журнала событий, например, по фильтру local-block из предыдущего примера, можно при помощи команды (запрещающие фильтры помещают адреса в так называемый "чёрный" список - blacklist).

Команда в примере ниже включает протоколирование запросов по адресам, закрытым фильтром local-block из предыдущего примера.

Пример - Включение протоколирования#
  1. Включение протоколирования всего, что перехватывается фильтром local-block. Параметр default добавляется автоматически для верхнеуровневых списков,так как могут иметь место и другие списки local-block, задаваемые в соответствии с правилами 'squidguard rule xxx': 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard log local-block-default
  2. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  3. Просмотр текущей конфигурации веб-прокси в этом контексте: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
    [edit]
admin@edge# show service webproxy
  listen-address 192.168.1.254 {
      enable-ssl
  }
  ssl {
      x509-cert WEB_PROXY_CA
  }
  url-filtering {
      squidguard {
          local-block youtube.com
          local-block facebook.com
          log local-block-default
      }
      ssl {
          block-server {
              name vk.com
          }
          bump-server {
              regex ".*"
          }
      }
  }

Фильтрация по категории данных#

Команды из примера ниже включат блокирование адресов из заранее определённых в Numa Edge категорий "реклама" (banner), "шпионское ПО" (spyware) и "азартные игры" (gambling).

Пример – Включение фильтрации по категориям адресов#
  1. Включение блокирования адресов из категории "реклама": 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard block-category banner
  2. Включение блокирования адресов из категории "шпионское ПО":
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard block-category spyware
  3. Включение блокирования адресов из категории "азартные игры": 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard block-category gambling
  4. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  5. Просмотр текущей конфигурации веб-прокси в этом контексте: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
    [edit]
admin@edge# show service webproxy
  listen-address 192.168.1.254 {
      enable-ssl
  }
  ssl {
      x509-cert WEB_PROXY_CA
  }
  url-filtering {
      squidguard {
          block-category banner
          block-category spyware
          block-category gambling
          local-block youtube.com
          local-block facebook.com
          log local-block-default
      }
      ssl {
          block-server {
              name vk.com
          }
          bump-server {
              regex ".*"
          }
      }
  }

Фильтрация по ключевому слову#

Команды из примера ниже запрещают доступ к сайтам, адреса которых содержат указанную последовательность символов. В этом примере блокируется доступ ко всем сайтам в доменной зоне Китая (".cn").

Пример – Включение фильтрации по ключевому слову#
  1. Запрет доступа ко всем сайтам доменной зоны Китая: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard local-block-keyword “.cn”
  2. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  3. Просмотр текущей конфигурации веб-прокси в этом контексте: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
    [edit]
admin@edge# show service webproxy
  listen-address 192.168.1.254 {
      enable-ssl
  }
  ssl {
      x509-cert WEB_PROXY_CA
  }
  url-filtering {
      squidguard {
          block-category banner
          block-category spyware
          block-category gambling
          local-block youtube.com
          local-block facebook.com
          local-block-keyword “.cn”
          log local-block-default
      }
      ssl {
          block-server {
              name vk.com
          }
          bump-server {
              regex ".*"
          }
      }
  }

Допуск к отдельным сайтам#

Команды из примера ниже разрешают доступ к отдельным сайтам из заблокированных категорий. В этом примере открывается доступ к сайту по фиктивному адресу www.company-banner.com, хотя он (в рамках примера) числится в категории "реклама", доступ к сайтам из которой закрыт. Такое возможно благодаря тому, что приоритет фильтра local-ok выше приоритета фильтра block-category и соответствующее разрешающее действие сработает раньше запрещающего и тем самым остановит сверку.

Пример – Допуск к отдельным сайтам#
  1. Предоставление пользователям доступа к фиктивному сайту www.company-banner.com:
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard local-ok www.company-banner.com
  2. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  3. Просмотр текущей конфигурации веб-прокси в этом контексте: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
    [edit]
admin@edge# show service webproxy
  listen-address 192.168.1.254 {
      enable-ssl
  }
  ssl {
      x509-cert WEB_PROXY_CA
  }
  url-filtering {
      squidguard {
          block-category banner
          block-category spyware
          block-category gambling
          local-block youtube.com
          local-block facebook.com
          local-block-keyword “.cn”
          local-ok www.company-banner.com
          log local-block-default
      }
      ssl {
          block-server {
              name vk.com
          }
          bump-server {
              regex ".*"
          }
      }
  }

Перенаправление запросов пользователей#

По умолчанию, в ответ на запрос пользователя к заблокированному сайту возвращается страница другого, заранее определённого сайта. Адрес этой страницы задаётся при помощи команды redirect-url, также можно указать причину (по сути - категорию), по которой доступ по запрошенному пользователем адресу был закрыт. Команды из примера ниже указывают системе Numa Edge показывать страницу с категорией и адресом заблокированного сайта, к которому пытается обратиться пользователь.

Пример - Установка адреса страницы с сайта-подмены для заблокированных адресов#
  1. Установка адреса нужной страницы. Приведённый в примере URL вызовет обращение. Этот скрипт вернёт страницу с заблокированным адресом и причиной, по которой доступ к URL был закрыт (обратите внимание на регистр символов в URL - в рамках HTTP он имеет значение): 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard redirect-url “http://192.168.1.254/cgi-bin/squidGuard-simple.cgi?targetclass=%t&url=%u”
  2. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  3. Просмотр текущей конфигурации веб-прокси в этом контексте: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
    [edit]
admin@edge# show service webproxy
  listen-address 192.168.1.254 {
      enable-ssl
  }
  ssl {
      x509-cert WEB_PROXY_CA
  }
  url-filtering {
      squidguard {
          block-category banner
          block-category spyware
          block-category gambling
          local-block youtube.com
          local-block facebook.com
          local-block-keyword “.cn”
          local-ok www.company-banner.com7
          log local-block-default
          redirect-url http://192.168.1.254/cgi-bin/squidGuard-simple.cgitargetclass=%t&url=%u
      }
      ssl {
          block-server {
              name vk.com
          }
          bump-server {
              regex ".*"
          }
      }
  }

Поддержка разных групп пользователей#

До этого момента во всех примерах подразумевалось, что все пользователи равноправны. Однако, при решении каких-то задач может возникнуть потребность обрабатывать запросы одних пользователей не так, как запросы других. Команда source-group позволяет сгруппировать пользователей по IP-адресам их систем, либо по адресам сетей, к которым относятся их системы.

Пример – Настройка доступа в зависимости от группы#
  1. Очистка существующей конфигурации в отношении фильтрации запросов: 
    1
2
    [edit]
admin@edge# delete service webproxy url-filtering
  2. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  3. Регулярное выражение обозначающее все возможные домены, где символ "." описывает любой символ, а символ "*" – любое количество повторений:
    1
2
    [edit] 
admin@edge# set service webproxy url-filtering ssl bump-server regex ".*"
  4. Возвращать в ответ на запросы к заблокированным сайтам титульную страницу сайта google.ru: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard redirect-url "https://google.ru"
  5. Создание группы для администраторов (с единственным IP-адресом): 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard source-group ADMIN address 10.0.5.15
  6. Создание группы для учителей (с одной подсетью): 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard source-group TEACHERS address 10.0.5.0/24
  7. Создание группы для учащихся (с первой из двух подсетей): 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard source-group STUDENTS address 10.0.1.0/24
  8. Создание группы для учащихся (со второй из двух подсетей): 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard source-group STUDENTS address 10.0.2.0/24
  9. Создание правила для фильтрации запросов от группы ADMIN. В данном случае ограничений нет: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard rule 10 source-group ADMIN
  10. Создание правила для фильтрации запросов от группы TEACHERS: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard rule 20 source-group TEACHERS
  11. Запрет доступа пользователей из группы TEACHERS к сайтам из категории “porn” ("сайты с порнографическим содержимым"): 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard rule 20 block-category porn
  12. Запрет доступа пользователей из группы TEACHERS к сайтам из категории “shopping” ("сайты интернет-магазинов"):
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard rule 20 block-category social-networks
  13. Создание правила для фильтрации запросов от группы STUDENTS: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard rule 30 source-group STUDENTS
  14. Запрет доступа пользователей из группы STUDENTS к сайтам из категории “warez” ("краденое/взломанное ПО"): 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard rule 30 block-category warez
  15. Запрет доступа пользователей из группы STUDENTS к сайтам из категории “drugs” ("наркотики"): 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard rule 30 block-category drugs
  16. Запрет доступа пользователей из группы STUDENTS к сайтам из категории “filehosting” ("файлообмен"): 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard rule 30 block-category filehosting
  17. Запрет доступа пользователей из группы STUDENTS к сайтам из категории “audio-video” ("аудио-видео содержимое"): 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard rule 30 block-category audio-video
  18. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  19. Просмотр текущей конфигурации веб-прокси в этом контексте:
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
    [edit]
admin@edge# show service webproxy  
  listen-address 192.168.1.254 {
      enable-ssl
  }
  ssl {
      x509-cert WEB_PROXY_CA
  }
  url-filtering {
      squidguard {
          redirect-url https://google.ru
          rule 10 {
              source-group ADMIN
          }
          rule 20 {
              block-category porn
              block-category social-networks
              source-group TEACHERS
          }
          rule 30 {
              block-category warez
              block-category drugs
              block-category filehosting
              block-category audio-video
              source-group STUDENTS
          }
          source-group ADMIN {
              address 10.0.5.15
          }
          source-group STUDENTS {
              address 10.0.1.0/24
              address 10.0.2.0/24
          }
          source-group TEACHERS {
              address 10.0.5.0/24
          }
      }
      ssl {
          bump-server {
              regex ".*"
          }
      }
  }

Учёт разных промежутков времени#

В предыдущем примере правила фильтрации применялись независимо от момента времени. Для привязки связанных с группой правил фильтрации к промежуткам времени вроде будних дней и времени суток применяется команда time-period.

Команды из примера ниже показывают, как добавить в правила фильтрации учёт временных промежутков. В этом примере вводится новое правило с номером 25, в котором пользователям из группы TEACHERS закрывается доступ к сайтам из категории «porn» во внеучебное время (временной интервал AFTERHOURS), при этом остальные категории не блокируются. Вместе с тем существующее правило 20 дополняется временным промежутком SCHOOLHOURS, благодаря чему оно актуально только в учебные часы. В результате получается, что в учебные часы у пользователей группы TEACHERS закрыт доступ к сайтам из категорий «porn» и «shopping», а во внеучебные - только к «porn».

Пример – Применение правил в определённое время суток#
  1. Определение временного периода под названием SCHOOLHOURS, обозначающего рабочие (учебные) часы: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard time-period SCHOOLHOURS day workday time "09:00-12:00, 13:00-16:00"
  2. Определение временного периода под названием AFTERHOURS, обозначающего нерабочее время: 
    1
2
3
4
    [edit]
admin@edge# set service webproxy url-filtering squidguard time-period AFTERHOURS day weekend time "00:00-24:00"
[edit]
admin@edge# set service webproxy url-filtering squidguard time-period AFTERHOURS day workday time "00:00-19:00, 12:00-13:00, 16:00-00:00"
  3. Уточнение правила 20 этим промежутком времени - теперь оно актуально только во время учебных часов: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard rule 20 time-period SCHOOLHOURS
  4. Создание нового правила для фильтрации запросов от группы TEACHERS ("преподаватели") во внеучебное время: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard rule 25 source-group TEACHERS
  5. Правило 25 актуально только во внеучебное время: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard rule 25 time-period AFTERHOURS
  6. Закрытие доступа пользователей из группы TEACHERS к сайтам только из категории “porn”: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard rule 25 block-category porn
  7. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  8. Просмотр текущей конфигурации веб-прокси в этом контексте: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
    [edit]
admin@edge# show service webproxy  
  listen-address 192.168.1.254 {
      enable-ssl
  }
  ssl {
      x509-cert WEB_PROXY_CA
  }
  url-filtering {
      squidguard {
          redirect-url https://google.ru
          rule 10 {
              source-group ADMIN
          }
          rule 20 {
              block-category porn
              block-category social-networks
              source-group TEACHERS
               time-period SCHOOLHOURS
          }

          rule 25 {
              block-category porn
              source-group TEACHERS
              time-period AFTERHOURS
          }
          rule 30 {
              block-category warez
              block-category drugs
              block-category filehosting
              block-category audio-video
              source-group STUDENTS
          }
          source-group ADMIN {
              address 10.0.5.15
          }
          source-group STUDENTS {
              address 10.0.1.0/24
              address 10.0.2.0/24
          }
          source-group TEACHERS {
              address 10.0.5.0/24
          }
          time-period AFTERHOURS {
              day workday {
                  time "00:00-19:00, 12:00-13:00, 16:00-00:00"
              }
              day weekend {
                  time 00:00-24:00
              }
          }
          time-period SCHOOLHOURS {
              day workday {
                  time "09:00-12:00, 13:00-16:00"
              }
          }
      }
      ssl {
          bump-server {
              regex ".*"
          }
      }
  }

Работа с "белым" списком#

Распространённым способом фильтрации веб-содержимого является предоставление доступа ко всем сайтам за исключением некоторых заблокированных (составляющих, таким образом, "чёрный" список). Однако, бывают ситуации, когда необходимо, наоборот, закрыть доступ ко всем сайтам за исключением некоторых разрешённых (составляющих "белый" список). В примере ниже показано создание "белого" списка.

Пример – Определение "белого" списка#
  1. Очистка существующей конфигурации: 
    1
2
    [edit]
admin@edge# delete service webproxy url-filtering
  2. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  3. Регулярное выражение обозначающее все возможные домены, где символ "." описывает любой символ, а символ "*" – любое количество повторений:
    1
2
    [edit]
admin@edge# set service webproxy url-filtering ssl bump-server regex ".*"
  4. Возвращать в ответ на запросы к заблокированным сайтам титульную страницу сайта google.ru: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard redirect-url "https://google.ru"
  5. Запрещение доступа ко всем сайтам в качестве действия по умолчанию (т.е. если явно не указано иное): 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard default-action block
  6. Разрешение доступа к сайту “numatech.ru”: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard local-ok numatech.ru
  7. Разрешение доступа к сайту “yandex.ru”: 
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard local-ok yandex.ru
  8. Разрешение доступа к сайту “google.ru”:
    1
2
    [edit]
admin@edge# set service webproxy url-filtering squidguard local-ok google.ru
  9. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  10. Просмотр текущей конфигурации веб-прокси в этом контексте:
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
    [edit]
admin@edge# show service webproxy  
  listen-address 192.168.1.254 {
      enable-ssl
  }
  ssl {
      x509-cert WEB_PROXY_CA
  }
  url-filtering {
      squidguard {
         default-action block
         local-ok numatech.ru
         local-ok yandex.ru
         local-ok google.ru
         redirect-url https://google.ru
      }
   }
      ssl {
          bump-server {
              regex ".*"
          }
      }

Настройка аутентификации пользователей на основе NTLM#

В примере ниже приведена настройка аутентификации пользователей прокси-сервера на основе NTLM. На рисунке приведена используемая схема сети.

Аутентификация-пользователей-прокси-на-основе-протокола-NTLM

Аутентификация пользователей прокси на основе протокола NTLM

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

  • Настройка клиентской машины:
    • Пользователь должен быть членом домена и находится в базе данных контроллера домена Microsoft Active Directory. Компьютер клиента должен находиться в базе контроллера домена.
    • В настройках прокси веб-обозревателя должно быть установлено полное доменное имя (FQDN) прокси-сервера (или IP-адрес) и номер порта (например, 3128).
  • Настройка сервера Microsoft Active Directory:
    • Должен быть настроен сервер Active Directory.
    • Должен быть настроен сервер DNS. На сервере DNS должна быть создана запись с доменным именем прокси-сервера.
    • В домене необходимо создать учетную запись для прокси-сервера с правами на ввод компьютеров в домен.
  • В данном примере предполагается следующее:
    • На компьютере под управлением Windows, являющимся PDC, настроен домен TESTDOMAIN.LOCAL.
    • В настройке сервера DNS создана запись с доменным именем для прокси-сервера edge.testdomain.local.
    • PDC имеет IP-адрес 192.168.1.100.
    • В базе AD создана учетная запись для прокси-сервера с правами администратора.

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

Для настройки аутентификации пользователей прокси на основе NTLM, необходимо выполнить следующие шаги в режиме настройки:

Пример – Удаление настроенных выше правил для "прозрачного" режима#
  1. Удаление перенаправления https трафика на порт 3129: 
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 10
  2. Удаление перенаправления http трафика на порт 3128:
    1
2
    [edit]
admin@edge#set service nat ipv4 rule 20
  3. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
Пример – Настройка аутентификации пользователей прокси на основе NTLM#
  1. Отключение "прозрачного" режима работы прокси-сервера: 
    1
2
    [edit]
admin@edge# set service webproxy listen-address 192.168.1.254 disable-transparent
  2. Установка аутентификации клиентов на основе NTLM: 
    1
2
    [edit]
admin@edge# set service webproxy authentication method ntlm
  3. Указание имени компьютера в домене:
    1
2
    [edit]
admin@edge# set service webproxy authentication ntlm name edge
  4. Указание пароля для учетной записи, созданной в AD для прокси сервера: 
    1
2
    [edit]
admin@edge# set service webproxy authentication ntlm password 123
  5. Указание адреса контроллера домена: 
    1
2
    [edit]
admin@edge# set service webproxy authentication ntlm pdc 192.168.1.100
  6. Указание имени пользователя: 
    1
2
    [edit]
admin@edge# set service webproxy authentication ntlm user proxy
  7. Указание имени домена: 
    1
2
    [edit]
admin@edge# set service webproxy authentication ntlm workgroup testdomain
  8. Фиксация конфигурации: 
    1
2
    [edit]
admin@edge# commit

Настройка аутентификации пользователей на основе LDAP#

Numa Edge поддерживает возможность проверки подлинности клиентов прокси с использованием службы каталогов на основе протокола LDAP. Для этого необходимо настроить параметры подключения к серверу LDAP, для этого используется ветвь конфигурации system ldap-server.

При использовании аутентификации пользователей возможна работа только в непрозрачном режиме прокси, при этом на клиентском ПО должны быть соответствующим образом прописаны настройки прокси-сервера.

При использовании аутентификации на основе LDAP, пользователю выдается приглашение на ввод регистрационного имени и пароля.

Аутентификация-пользователей-прокси-на-основе-протокола-LDAP

Аутентификация пользователей прокси на основе протокола LDAP

В примере ниже приведена настройка параметров подключения к серверу LDAP.

Пример – Настройка параметров подключения к серверу LDAP#
  1. Указание имени привязки, используемого для подключения к серверу LDAP: 
    1
2
    [edit]
admin@edge# set system ldap-server dn cn=edgeproxy,dc=domain,dc=local
  2. Указание IP-адреса сервера LDAP: 
    1
2
    [edit]
admin@edge# set system ldap-server host 192.168.1.100
  3. Указание базового DN, в котором будет осуществляться поиск:
    1
2
    [edit]
admin@edge# set system ldap-server basedn dc=domain,dc=local
  4. Указание пароля для аутентификации на сервере LDAP: 
    1
2
    [edit]
admin@edge# set system ldap-server password testpassword
  5. Указание используемого для подключения к серверу LDAP номера сетевого порта: 
    1
2
    [edit]
admin@edge# set system ldap-server port 389
  6. Указание корневого объекта каталога, начиная от которого необходимо производить поиск учетных записей пользователей: 
    1
2
    [edit]
admin@edge# set system ldap-server userbasedn cn=edgeproxy,dc= domain,dc=local
  7. Указание корневого объекта каталога, начиная от которого необходимо производить поиск учетных записей пользователей: 
    1
2
    [edit]
admin@edge# set system ldap-server groupbasedn cn=groups,dc= domain,dc=local
  8. Фиксация конфигурации: 
    1
2
    [edit]
admin@edge# commit

В примере ниже приведена настройка параметров прокси-сервера для включения аутентификации на основе протокола LDAP.

Пример – Включение аутентификации на основе LDAP в параметрах прокси-сервера#
  1. Указание аутентификации на основе LDAP: 
    1
2
    [edit]
admin@edge#set service webproxy authentication method ldap
  2. Отключение прозрачного режима: 
    1
2
    [edit]
admin@edge#set service webproxy listen-address 192.168.1.254 disable-transparent
  3. Фиксация конфигурации: 
    1
2
    [edit]
admin@edge# commit