Кившенко Алексей, 1880

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

При рассмотрении вариантов в качестве примера возьмем сеть, в которой требуется опубликовать:

1. Корпоративный почтовый сервер (Web-mail).
2. Корпоративный терминальный сервер (RDP).
3. Extranet сервис для контрагентов (Web-API).

Вариант 1. Плоская сеть

В данном варианте все узлы корпоративной сети содержатся в одной, общей для всех сети («Внутренняя сеть»), в рамках которой коммуникации между ними не ограничиваются. Сеть подключена к Интернет через пограничный маршрутизатор/межсетевой экран (далее - IFW ).

Доступ узлов в Интернет осуществляется через NAT , а доступ к сервисам из Интернет через Port forwarding .

Плюсы варианта :

1. Минимальные требования к функционалу IFW (можно сделать практически на любом, даже домашнем роутере).
2. Минимальные требования к знаниям специалиста, осуществляющего реализацию варианта.

Минусы варианта :

1. Минимальный уровень безопасности. В случае взлома, при котором Нарушитель получит контроль над одним из опубликованных в Интернете серверов, ему для дальнейшей атаки становятся доступны все остальные узлы и каналы связи корпоративной сети.

Аналогия с реальной жизнью
Подобную сеть можно сравнить с компанией, где персонал и клиенты находятся в одной общей комнате (open space)


hrmaximum.ru

Вариант 2. DMZ

Для устранения указанного ранее недостатка узлы сети, доступные из Интернет, помещают в специально выделенный сегмент – демилитаризованную зону (DMZ). DMZ организуется с помощью межсетевых экранов, отделяющих ее от Интернет (IFW ) и от внутренней сети (DFW ).


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

1. Из внутренней сети можно инициировать соединения в DMZ и в WAN (Wide Area Network).
2. Из DMZ можно инициировать соединения в WAN.
3. Из WAN можно инициировать соединения в DMZ.
4. Инициация соединений из WAN и DMZ ко внутренней сети запрещена.

Плюсы варианта:

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

Минусы варианта:

1. Сам по себе вынос серверов в DMZ не повышает их защищенность.
2. Необходим дополнительный МЭ для отделения DMZ от внутренней сети.

Аналогия с реальной жизнью
Данный вариант архитектуры сети похож на организацию рабочей и клиентской зон в компании, где клиенты могут находиться только в клиентской зоне, а персонал может быть как в клиентской, так и в рабочих зонах. DMZ сегмент - это как раз и есть аналог клиентской зоны.


autobam.ru

Вариант 3. Разделение сервисов на Front-End и Back-End

Как уже отмечалось ранее, размещение сервера в DMZ никоим образом не улучшает безопасность самого сервиса. Одним из вариантов исправления ситуации является разделение функционала сервиса на две части: Front-End и Back-End . При этом каждая часть располагается на отдельном сервере, между которыми организуется сетевое взаимодействие. Сервера Front-End, реализующие функционал взаимодействия с клиентами, находящимися в Интернет, размещают в DMZ, а сервера Back-End, реализующие остальной функционал, оставляют во внутренней сети. Для взаимодействия между ними на DFW создают правила, разрешающие инициацию подключений от Front-End к Back-End.

В качестве примера рассмотрим корпоративный почтовый сервис, обслуживающий клиентов как изнутри сети, так и из Интернет. Клиенты изнутри используют POP3/SMTP, а клиенты из Интернет работают через Web-интерфейс. Обычно на этапе внедрения компании выбирают наиболее простой способ развертывания сервиса и ставят все его компоненты на один сервер. Затем, по мере осознания необходимости обеспечения информационной безопасности, функционал сервиса разделяют на части, и та часть, что отвечает за обслуживание клиентов из Интернет (Front-End), выносится на отдельный сервер, который по сети взаимодействует с сервером, реализующим оставшийся функционал (Back-End). При этом Front-End размещают в DMZ, а Back-End остается во внутреннем сегменте. Для связи между Front-End и Back-End на DFW создают правило, разрешающее, инициацию соединений от Front-End к Back-End.

Плюсы варианта:

1. В общем случае атаки, направленные против защищаемого сервиса, могут «споткнуться» об Front-End, что позволит нейтрализовать или существенно снизить возможный ущерб. Например, атаки типа TCP SYN Flood или slow http read , направленные на сервис, приведут к тому, что Front-End сервер может оказаться недоступен, в то время как Back-End будет продолжать нормально функционировать и обслуживать пользователей.
2. В общем случае на Back-End сервере может не быть доступа в Интернет, что в случае его взлома (например, локально запущенным вредоносным кодом) затруднит удаленное управление им из Интернет.
3. Front-End хорошо подходит для размещения на нем межсетевого экрана уровня приложений (например, Web application firewall) или системы предотвращения вторжений (IPS, например snort).

Минусы варианта:

1. Для связи между Front-End и Back-End на DFW создается правило, разрешающее инициацию соединения из DMZ во внутреннюю сеть, что порождает угрозы, связанные с использованием данного правила со стороны других узлов в DMZ (например, за счет реализации атак IP spoofing, ARP poisoning и т. д.)
2. Не все сервисы могут быть разделены на Front-End и Back-End.
3. В компании должны быть реализованы бизнес-процессы актуализации правил межсетевого экранирования.
4. В компании должны быть реализованы механизмы защиты от атак со стороны Нарушителей, получивших доступ к серверу в DMZ.

Примечания

1. В реальной жизни даже без разделения серверов на Front-End и Back-End серверам из DMZ очень часто необходимо обращаться к серверам, находящимся во внутренней сети, поэтому указанные минусы данного варианта будут также справедливы и для предыдущего рассмотренного варианта.
2. Если рассматривать защиту приложений, работающих через Web-интерфейс, то даже если сервер не поддерживает разнесение функций на Front-End и Back-End, применение http reverse proxy сервера (например, nginx) в качестве Front-End позволит минимизировать риски, связанные с атаками на отказ в обслуживании. Например, атаки типа SYN flood могут сделать http reverse proxy недоступным, в то время как Back-End будет продолжать работать.

Аналогия с реальной жизнью
Данный вариант по сути похож на организацию труда, при которой для высоко загруженных работников используют помощников - секретарей. Тогда Back-End будет аналогом загруженного работника, а Front-End аналогом секретаря.


mln.kz

Вариант 4. Защищенный DMZ

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

Защита от атак, связанных с DHCP

Не смотря на то, что DHCP предназначен для автоматизации конфигурирования IP-адресов рабочих станций, в некоторых компаниях встречаются случаи, когда через DHCP выдаются IP-адерса для серверов, но это довольно плохая практика. Поэтому для защиты от Rogue DHCP Server , DHCP starvation рекомендуется полный отказ от DHCP в DMZ.

Защита от атак MAC flood

Для защиты от MAC flood проводят настройку на портах коммутатора на предмет ограничения предельной интенсивности широковещательного трафика (поскольку обычно при данных атаках генерируется широковещательный трафик (broadcast)). Атаки, связанные с использованием конкретных (unicast) сетевых адресов, будут заблокированы MAC фильтрацией, которую мы рассмотрели ранее.

Защита от атак UDP flood

Защита от данного типа атак производится аналогично защите от MAC flood, за исключением того, что фильтрация осуществляется на уровне IP (L3).

Защита от атак TCP SYN flood

Для защиты от данной атаки возможны варианты:

1. Защита на узле сети с помощью технологии TCP SYN Cookie .
2. Защита на уровне межсетевого экрана (при условии разделения DMZ на подсети) путем ограничения интенсивности трафика, содержащего запросы TCP SYN.

Защита от атак на сетевые службы и Web-приложения

Универсального решения данной проблемы нет, но устоявшейся практикой является внедрение процессов управления уязвимостями ПО (выявление, установка патчей и т.д., например, так), а также использование систем обнаружения и предотвращения вторжений (IDS/IPS).

Защита от атак на обход средств аутентификации

Как и для предыдущего случая универсального решения данной проблемы нет.
Обычно в случае большого числа неудачных попыток авторизации учетные записи, для избежания подборов аутентификационных данных (например, пароля) блокируют. Но подобный подход довольно спорный, и вот почему.
Во-первых, Нарушитель может проводить подбор аутентификационной информации с интенсивностью, не приводящей к блокировке учетных записей (встречаются случаи, когда пароль подбирался в течении нескольких месяцев с интервалом между попытками в несколько десятков минут).
Во-вторых, данную особенность можно использовать для атак типа отказ в обслуживании, при которых Нарушитель будет умышленно проводить большое количество попыток авторизации для того, чтобы заблокировать учетные записи.
Наиболее эффективным вариантом от атак данного класса будет использование систем IDS/IPS, которые при обнаружении попыток подбора паролей будут блокировать не учетную запись, а источник, откуда данный подбор происходит (например, блокировать IP-адрес Нарушителя).

Итоговый перечень защитных мер по данному варианту:

1. DMZ разделяется на IP-подсети из расчета отдельная подсеть для каждого узла.
2. IP адреса назначаются вручную администраторами. DHCP не используется.
3. На сетевых интерфейсах, к которым подключены узлы DMZ, активируется MAC и IP фильтрация, ограничения по интенсивности широковещательного трафика и трафика, содержащего TCP SYN запросы.
4. На коммутаторах отключается автоматическое согласование типов портов, запрещается использование native VLAN.
5. На узлах DMZ и серверах внутренней сети, к которым данные узлы подключаются, настраивается TCP SYN Cookie.
6. В отношении узлов DMZ (и желательно остальной сети) внедряется управление уязвимостями ПО.
7. В DMZ-сегменте внедряются системы обнаружения и предотвращения вторжений IDS/IPS.

Плюсы варианта:

1. Высокая степень безопасности.

Минусы варианта:

1. Повышенные требования к функциональным возможностям оборудования.
2. Трудозатраты во внедрении и поддержке.

Аналогия с реальной жизнью
Если ранее DMZ мы сравнили с клиентской зоной, оснащенной диванчиками и пуфиками, то защищенный DMZ будет больше похож на бронированную кассу.


valmax.com.ua

Вариант 5. Back connect

Рассмотренные в предыдущем варианте меры защиты были основаны на том, что в сети присутствовало устройство (коммутатор / маршрутизатор / межсетевой экран), способное их реализовывать. Но на практике, например, при использовании виртуальной инфраструктуры (виртуальные коммутаторы зачастую имеют очень ограниченные возможности), подобного устройства может и не быть.

В этих условиях Нарушителю становятся доступны многие из рассмотренных ранее атак, наиболее опасными из которых будут:

• атаки, позволяющие перехватывать и модифицировать трафик (ARP Poisoning, CAM table overflow + TCP session hijacking и др.);
• атаки, связанные с эксплуатацией уязвимостей серверов внутренней сети, к которым можно инициировать подключения из DMZ (что возможно путем обхода правил фильтрации DFW за счет IP и MAC spoofing).

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

Таким образом, перед нами встает задача защитить сервера внутренней сети от атак Нарушителя как из DMZ, так и из внутренней сети (заражение АРМа трояном можно интерпретировать как действия Нарушителя из внутренней сети).

Предлагаемый далее подход направлен на уменьшение числа каналов, через которые Нарушитель может атаковать сервера, а таких канала как минимум два. Первый это правило на DFW , разрешающее доступ к серверу внутренней сети из DMZ (пусть даже и с ограничением по IP-адресам), а второй - это открытый на сервере сетевой порт, по которому ожидаются запросы на подключение.

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

Но проблема в том, что обычные серверные службы не умеют работать подобным образом, и для реализации указанного подхода необходимо применять сетевое туннелирование, реализованное, например, с помощью SSH или VPN, а уже в рамках туннелей разрешать подключения от сервера в DMZ к серверу внутренней сети.

Общая схема работы данного варианта выглядит следующим образом:

1. На сервер в DMZ инсталлируется SSH/VPN сервер, а на сервер во внутренней сети инсталлируется SSH/VPN клиент.
2. Сервер внутренней сети инициирует построение сетевого туннеля до сервера в DMZ. Туннель строится с взаимной аутентификацией клиента и сервера.
3. Сервер из DMZ в рамках построенного туннеля инициирует соединение до сервера во внутренней сети, по которому передаются защищаемые данные.
4. На сервере внутренней сети настраивается локальный межсетевой экран, фильтрующий трафик, проходящий по туннелю.

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

• Кроссплатформенность. Можно организовывать связь на серверах с разными операционными системами.
• Возможность построения туннелей с взаимной аутентификацией клиента и сервера.
• Возможность использования сертифицированной криптографии .

На первый взгляд может показаться, что данная схема излишне усложнена и что, раз на сервере внутренней сети все равно нужно устанавливать локальный межсетевой экран, то проще сделать, чтобы сервер из DMZ, как обычно, сам подключался к серверу внутренней сети, но делал это по шифрованному соединению. Действительно, данный вариант закроет много проблем, но он не сможет обеспечить главного - защиту от атак на уязвимости сервера внутренней сети, совершаемых за счет обхода межсетевого экрана с помощью IP и MAC spoofing.

Плюсы варианта:

1. Архитектурное уменьшение количества векторов атак на защищаемый сервер внутренней сети.
2. Обеспечение безопасности в условиях отсутствия фильтрации сетевого трафика.
3. Защита данных, передаваемых по сети, от несанкционированного просмотра и изменения.
4. Возможность избирательного повышения уровня безопасности сервисов.
5. Возможность реализации двухконтурной системы защиты, где первый контур обеспечивается с помощью межсетевого экранирования, а второй организуется на базе данного варианта.

Минусы варианта:

1. Внедрение и сопровождение данного варианта защиты требует дополнительных трудовых затрат.
2. Несовместимость с сетевыми системами обнаружения и предотвращения вторжений (IDS/IPS).
3. Дополнительная вычислительная нагрузка на сервера.

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

корпоративные сети

Добавить метки Записей: 4

Удаленное управление доступом в Интернет (родительский контроль)

Это руководство описывает процесс настройки компьютеров под управлением операционных систем семейства Windows XP, 7 или Linux (Ubuntu) для удаленного управления доступом к сайтам сети Интернет.

Руководство подробно не описывает приемы работы с сервисом Rejector, речь о котором пойдет ниже, оно лишь позволяет настроить компьютер так, чтобы в полной мере использовать его возможности.

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

Введение

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

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

В таких случаях вам помогут специальные программы по ограничению и контролю доступа к сети. С помощью них вы можете оградить вашего ребенка от негативных влияний Интернета, но при этом предоставить свободу действий. Одной из таких средств Система контроля доступа к Интернету Rejector.

Rejector — это централизованный проект для контроля доступа к сети Интернет. Он позволит вам оградить детей и подростков от опасной информации. По сути Rejector — это DNS-сервер с возможностью удаленного им управления.

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

Вы регистрируетесь, добавляете свои IP, настраиваете параметры доступа. Вы можете использовать сервис и без регистрации, но тогда вы не сможете использовать все его возможности.

Ваши компьютеры настраиваются так, что бы все DNS запросы посылались на DNS сервера Rejector 95.154.128.32 и 176.9.118.232.

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

Эту страницу вы можете настроить на своё усмотрение.

Разрешенные запросы, прошедшие проверку, попадают в общий кэш запросов для быстрой выдачи всем клиентам.

Более подробное описание продукта Rejector вы можете найти на официальном сайте rejector.ru

Инструкция по настройке системы

1. Создадим пользователя с обычными правами

Обычно, при установке операционной системы создается пользователь с правами Администратора. Такой пользователь может производить все возможные действия, предоставляемые операционной системой в плоть до удаления самой системы.

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

В системе Windows это делается через Панель управления; в Linux создание пользователя доступно через Параметры системы.

2. Настроим сетевое соединение

Rejector — это сервис, который представляет собой, по сути, DNS сервер. Для работы с ним нужно прежде всего настроить сетевое соединение так, что бы DNS запросы посылались на DNS сервера Rejector 95.154.128.32 и 176.9.118.232.

В Windows и Linux это делается по разному.

Windows XP

Windows Vista

Подробная инструкция находится по адресу

Windows 7

Подробная инструкция находится по адресу

В большинстве операционных систем семейства Linux для настройки сети используется программа Network Manager. Для того, чтобы изменить DNS — сервер, делаем следующее:

Нажимаем ПКМ на индикаторе соединения и, в контекстном меню, выбираем пункт Изменить соединение

Если вы используете DHCP сервер при подключении к Интернету то, в параметрах IPv4 изменяем Способ настройки на Автоматический (DHCP, только адрес)

В поле Серверы DNS вводим два адреса через запятую 95.154.128.32, 176.9.118.232

Делаем соединение Доступным для всех пользователей и Автоматически подключаемым

3. Регистрируемся на сайте Rejector

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

4. Добавляем управляемую сеть

Зарегистрировавшись на сервисе, мы можем создавать необходимое число сетей или, что, в принципе, одно и тоже — клиентов, которыми мы будем управлять. Сети (Клиенты) идентифицируются на сервисе по их IP-адресу. Поэтому, чтобы управлять доступом в Интернет какого-то компьютера нужно знать его IP-адрес. Пока просто создадим Сеть через Панель управления на сайте Rejector по адресу.

Заполняем форму Добавления сети. Название сети — здесь вы можете указать имя вашего ребенка, если у него свой компьютер и вы хотите его контролировать. Статус — скорее всего, у вас будет Динамический IP-адрес (редкий провайдер выделяет для своих клиентов Статический адрес бесплатно), поэтому выбираем этот переключатель. Идентификатор сети — можно записать латиницей имя, которое вы указали в первом поле.

5. Отправка IP-адреса

Для работы сервиса, ему нужно постоянно «знать» IP-адрес клиента, который может меняется от подключения к подключению (Динамический IP-адрес). Это основная проблема, которая решается в этом руководстве.

Сами разработчики сервиса предлагают программу Rejector Agent, которая отправляет IP-адрес клиента на сервер. Но, эта программа не может работать автономно. Поэтому мы воспользуемся другой предоставленной возможностью. А именно — обновление с помощью HTTP-запроса (описание по ссылке).

Чтобы производить обновление сведений Клиента посредством HTTP-запроса в фоновом режиме, нам понадобится программа Curl. Эта программа способна отправлять забросы по протоколу HTTP в Интернет через командную строку. Параметры к этой программе мы зададим в скрипте; для Windows это будет bash-файл для Linux — sh.

Программа Curl распространяется свободно и имеет версию для Windows, поэтому мы будем использовать ее в обоих средах. Для Windows последнюю версию программы можно скачать по ссылке. Чтобы установить, достаточно распаковать содержимое поолученного архива в папку C:\WINDOWS\SYSTEM32 (это упростит запуск программы). В операционной системе семейства Linux она, скорее всего, уже будет установлена.

6. Скрипт регулярного обновления IP-адреса

На сайте предлагается следующий HTTP-запрос http://username:[email protected]/ni...,
который обновит значение IP адреса. Мы будем подставлять его в качестве параметра для программы curl.

Запрос на обновление адреса должен отправляться с того компьютера, который мы хотим контролировать. Из-за того что текстовый терминал обрабатывает команды особым образом, текст запроса пришлось немного изменить. Текст сценария для Windows и Linux приведен ниже.

Для Windows

:loop
curl "http://login%%40mail-server.com :password @updates.rejector.ru/nic/update?hostname=net-name "
# Делаем задержку в 300 секунд
ping -n 300 127.0.0.1 > NUL
echo 111
goto loop

Где login%%40mail-server.com — ваш почтовый ящик, с помощью которого регистрировались на Rejector (знак @ заменен на %%40); password — пароль; net-name — имя сети на сервисе Rejector.Поместите текст скрипта в обычный текстовый файл, замените расширение на.bat и вы получите исполняемый сценарий.

Для Linux

#! /usr/bin/sh
while true; do curl -u [email protected] :password "http://updates.rejector.ru/nic/update?hostname=... sleep 300; done;

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

Оба скрипта содержат пароль аккаунта Rejector в открытом виде, поэтому необходимо скрыть их содержимое от просмотра для обычного пользователя. В Linux и Windows это реализовано по разному

Для того, чтобы запретить просмотр и редактирование созданного нами этого необходимо изменить владельца и группу файла на root и запретить всем, кроме владельца, доступ к файлу. Если вы владеете навыками работы в командной строке, то вам нужно перейти с помощью команды cd в каталог с файлом скрипта и выполнить команду chown root:root skcript.sh и chmod 700 script.sh. ,Чтобы сделать то же самое в графической оболочке, нужно сначала запустить файловый менеджер с правами администратора, найти файл скрипта и изменить Права, используя контекстное меню.

Не вдаваясь в то как можно изменить права доступа к файлу подобно в Linux, применил следующее решение. Преобразуем наш исполняемый файл в EXE-файл, чтобы скрыть его содержимое. Для этой цели воспользуемся бесплатной программой Bat To Exe Converter. Предлагаю скачать ее русифицированную версию по ссылке или на официальном сайте программы. Программа не требует пояснений в работе. На входе ставим наш bat-файл на выходе получаем exe-файл.

7. Ставим на автоматический запуск

Осталось сделать последний шаг. Сделаем автоматический запуск программы вместе с запуском системы. В Linux и Windows это делается по разному.

Заходим в систему от имени Администратора и перемещаем наш исполняемый файл.exe в папку PogramFiles. В домашнем каталоге пользователя находим папку Главное меню , в ней Программы , Автозапуск куда и помещаем ярлык от нашей программы (это можно сделать путем перетаскивания самой программы с зажатой клавишей Shift). Готово.

Поместим исполняемый файл в папку /usr/bin . Отредактируем файл запуска локальных приложений системы /etc/rc.local , добавив в нем строчку перед exit 0.

/usr/bin/script.sh

где script.sh — имя нашего файла.

На этом настройка системы закончена. Можно заходить на сервис Rejector и настраивать режим работы сети.

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

Полный контроль для эффективного использования корпоративной сети

Ограничение интернета является одной из актуальных задач при формировании и обслуживании корпоративной сети. Не секрет, что зачастую сотрудники в офисах используют доступ в интернет совсем не для решения рабочих задач. В результате значительно снижается продуктивность работы, а значит, страдает эффективность бизнеса.

ИКС обладает широкими возможностями, в том числе делает возможным ограничение доступа, а также позволяет задавать ограничение интернет трафика по IP или по выбранным URL в сети. Все ограничения могут применяться для разных категорий и групп пользователей. За счет этого обеспечивается эффективное использование корпоративной сети, что улучшает производительность труда, а также снижается стоимость услуг провайдера.

Существует возможность легко обеспечить контроль скорости интернета в сети вашей компании за счет использования Proxy-server и Firewall. Это дает уверенность в том, что все работники используют Всемирную сеть только для решения рабочих задач. В результате значительно повышается эффективность работы офиса и растет прибыль.

Контроль использования интернета с помощью ИКС

Благодаря использованию ИКС обеспечивается удобный контроль доступа пользователей к интернету в корпоративной сети, который может быть реализован несколькими способами. Ограничить трафик интернета можно с помощью гибких настроек. В том числе предлагаются следующие функции:

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

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

• ввод логина и индивидуального пароля;
• получение доступа в интернет при входе под личной учетной записью («ActiveDirectory»);
• авторизация по определенному IP;
• использование специальной программы-агента.

Возможности по управлению пользователями

Существует возможность объединения пользователей локальной сети предприятия в группы в зависимости от любых признаков, например, от организационной структуры, служебных обязанностей и т.д. Это значительно повышает эффективность контроля доступа в локальных сетях. Каждой из таких групп можно назначать отдельного администратора. Контроль использования интернета может предусматривать блокировку или ограничение доступа отдельно для любой из существующих групп с возможностью задания подробного правила.

Также может предоставляться доступ в интернет для других предприятий с возможностью задания определенных ограничений. При этом для каждого из таких предприятий может создаваться отдельная группа с предоставлением пароля ее администратору. Это можно назвать передачей виртуального ИКС в пользование третьей стороне.

Работа с удаленными офисами

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

Покупка ИКС

Купить ИКС можно при помощи формы заказа на нашем сайте.

Нашей компанией осуществляется активная техническая поддержка клиентов по всем вопросам, связанным с использованием программы. Приобретая дополнительно Лицензию на обновления (Премиум) , Вы вручаете все заботы по установке, настройке и сопровождению ИКС в руки наших специалистов - идеальный вариант для тех, кто хочет купить и забыть, получая при этом максимальные выгоды от использования ИКС. За любыми консультациями обращайтесь в отдел продаж .

Тип организации

Выберите тип организации Образовательное учреждение Бюджетное учреждение Коммерческая организация

Цены НЕ РАСПРОСТРАНЯЮТСЯ на частные негосударственные учреждения и учреждения послевузовского профессионального образования

Редакции ИКС

Не требуется ИКС Стандарт ИКС ФСТЭК

Для расчета стоимости ФСТЭК обратитесь в отдел продаж

Тип поставки

ИКС ИКС + SkyDNS ИКС + Kaspersky Web Filtering

Тип лицензии

Новая лицензия Лицензия на обновления

Лицензия на обновления Премиум Расширение лицензии

Количество пользователей

Расширение лицензии

C до пользователей

Все большему числу предприятий сегодня становится необходимо подключить свои компьютерные сети к Интернету. За работу канала доступа обычно отвечает Интернет-провайдер (ISP), но и системному администратору компьютерной сети предприятия, даже небольшого, приходится решать ряд организационных и технологических задач. В данной статье мы не будем рассматривать почтовые службы, IP-телефонию и виртуальные частные сети (VPN), а ограничимся доступом к Web- и ftp-сервисам на базе ОС FreeBSD и прокси-сервера SQUID в корпоративной сети, охватывающей до 100 рабочих мест.

Два метода

Существует два основных метода предоставления пользователям корпоративной сети доступа к Web- и ftp-сервисам: посредством маршрутизации (трансляции) или через прокси-сервер.

В первом случае (рис. 1) доступ предоставляется по IP-адресу компьютера, на котором работает сотрудник. Такую схему можно полностью реализовать на базе программного решения - шлюза ОС FreeBSD и брандмауэра IPFW. Кроме того, существуют комплексные специализированные аппаратно-программные шлюзы. Для терминальных рабочих мест организация доступа по IP-адресам технически невозможна, так как все они используют один IP-адрес терминального сервера.

Для сопряжения рабочих станций пользователей с каналом Интернета используется шлюз в виде х86-сервера с установленными на нем ОС FreeBSD, программой NATD (обеспечивающей трансляцию внутренних IP-адресов в реальный IP-адрес сервера и обратно), IPFW, включенной маршрутизацией и двумя сетевыми интерфейсами: один из них "смотрит" в сторону локальной сети, другой подключен к провайдеру. На каждой клиентской машине в свойствах протокола TCP/IP сетевой карты необходимо прописать IP-адрес шлюза.

Во втором случае происходит авторизация пользователя по имени доступа (login) и паролю, выделенному сотруднику. Этот вариант, в частности, можно реализовать при помощи прокси-сервера SQUID и системы аутентификации ncsa_auth. Рассмотрим типовую схему (рис. 2), где SQUID установлен на шлюзе сети: сервер "смотрит" одним интерфейсом в локальную сеть, а другим подключен к Интернет-каналу. При такой установке SQUID для работы в Интернете (по HTTP, FTP и DNS) на машинах в локальной сети не требуется NATD и маршрутизации, поскольку все запросы к ресурсам Интернета SQUID отправляет "от себя" - с IP-адресом внешнего интерфейса шлюза. Службу DNS на компьютерах клиентов можно отключить, поскольку сам SQUID обращается к DNS.

Рис. 2. Доступ в Интернет через прокси-сервер.

Как правило, в корпоративной сети используется электронная почта, и для ее работы маршрутизация и NATD на шлюзе все равно понадобятся, но для Web-почты, работающей по протоколу HTTP, достаточно прокси-сервера SQUID.

"Скачанные" из Интернета данные SQUID передает пользователю и сохраняет в своем кэше. При повторном запросе эти данные извлекаются уже из кэша (если, конечно, Web-страница допускает кэширование), что происходит гораздо быстрее и не занимает к тому же канал доступа. Кроме более эффективного использования пропускной способности канала, получается экономия и на объеме трафика (по данным автора, в среднем за месяц она составляет 13%). Данные в кэше могут обновляться в зависимости от настройки самого прокси-сервера. При нажатии кнопки "Обновить" на панели управления браузера прокси-сервер принудительно копирует данные с Web-сервера, даже если они есть у него в кэше и не устарели (а заодно и обновляет их в кэше). Но некоторые страницы на Web-сайтах специально помечаются как некэшируемые, например, для целей повышенной актуальности.

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

Все эти процедуры, в зависимости от принятого типа доступа (по IP-адресу или через прокси-сервер), имеют свои особенности.

Аутентификация

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

Существует вариант подмены IP-адреса; правда, есть и вариант противодействия - статическая таблица ARP (Address Resolution Protocol - протокол преобразования IP-адресов в MAC-адреса/аппаратные адреса сетевых карт) на шлюзе, где прописаны соответствия IP-адрес - MAC-адрес сетевой карты рабочей станции. В общем, IP-аутентификация не обладает достаточной гибкостью и достоверностью и допускает только подсчет суммарного объема трафика.

В случае прокси-сервера пользователям корпоративной сети, получившим разрешение на доступ в Интернет (HTTP, FTP, ICQ), присваивается идентификационная пара: имя (login) и пароль (password). Подобная схема тоже позволяет выходить в Интернет с одного компьютера различным пользователям (главное, чтобы в клиентских программах были прописаны параметры прокси-сервера). Учет трафика будет вестись по каждому пользователю (логину) отдельно. Аутентификацию обеспечивает прокси-сервер SQUID под управлением ОС FreeBSD, а программная подсистема ncsa_auth хранит пароли в зашифрованном формате MD5. SQUID может использовать различные механизмы внешней аутентификации.

Работа в Интернете через прокси-сервер должна поддерживаться клиентским ПО: в его настройках прописывается DNS или IP-адрес прокси-сервера, а также его TCP-порт. Все современные браузеры и клиент ICQ поддерживают работу через прокси-сервер и аутентификацию на нем. Аутентификация может происходить при каждом подключении (запрашиваются логин и пароль) или быть постоянной (не требующей ввода имени и пароля, при этом в настройках клиентской программы прописывается имя пользователя из списка аутентификации прокси-сервера и пароль). Аутентификация происходит однократно и действует до закрытия программы-клиента. По окончании работы в Интернете пользователь просто закрывает браузер и тем самым прерывает разрешенную сессию.

Учет трафика

Учет трафика по IP-адресам рабочих станций ведется средствами IPFW - программного брандмауэра, встроенного в ядро ОС FreeBSD. Для достоверного учета трафика по пользователям при такой схеме доступа сотрудники должны выходить в Интернет только с закрепленных за ними рабочих мест, что, естественно, ограничивает гибкость и мобильность их работы.

Тем не менее такой подход имеет и свое преимущество - более точный учет суммарного объема трафика по IP-протоколу. Эта процедура реализуется с помощью установки двух правил COUNT брандмауэра IPFW:

Count ip from any to any in via de0 count ip from any to any out via de0

Первое правило учитывает входящий поток, второе - исходящий. Здесь de0 - внешний сетевой интерфейс шлюза, который имеет реальный IP-адрес в Интернете. В то же время при такой схеме невозможно протоколировать имена ресурсов, посещаемых пользователями, а также имена и размеры скачанных файлов.

При использовании прокси-сервера учет трафика ведется по протоколу HTTP, и объем таких данных меньше, чем величина IP-трафика. Но при аутентификации по пользователям SQUID заносит все данные о запросах (DNS-адреса сайтов, время получения запроса, объем скачанных файлов, источник - кэш SQUID или Интернет) в журнал по каждому пользователю, вне зависимости от IP-адреса клиентской машины.

Безопасность подключения к Интернету

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

Вредоносное воздействие вирусов трудно недооценить, но решение этой проблемы на 90% зависит от осведомленности пользователей - не запустит ли кто вложенный в письмо вирус. Вирусные атаки можно блокировать и отражать антивирусными программами на почтовых серверах (Dr.Web, McAfee, "Антивирус Касперского Business Optimal" и т. д.) и на компьютерах пользователей (Norton Antivirus, соответствующие продукты "Лаборатории Касперского" и т. д.). Главное при этом - своевременное обновление антивирусных баз.

Атаки извне, в зависимости от того, как организовано подключение, блокируются грамотной настройкой шлюза, применением прокси-сервера на шлюзе без NAT и маршрутизации, а также вынесением прокси-сервера, почтового и Web-сервера в "демилитаризованную зону" (DMZ, подсеть корпоративной сети, доступная из Интернета).

Утечки корпоративных данных имеют в основном организационную природу и составляют самую сложную проблему для службы безопасности предприятия. Существуют технические решения, минимизирующие возможность этого: в частности, закрытие всех TCP/UDP-портов на интерфейсе шлюза, "смотрящем" в локальную сеть (остается только порт прокси-сервера). Должна быть отключена маршрутизация и преобразование адресов (NAT) между Интернетом и внутренними ("серыми") IP-адресами сети предприятия.

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

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

Распределение пропускной способности канала

Для IP-схемы доступа разделение пропускной способности канала между пользователями можно реализовать средствами Pipes брандмауэра IPFW ОС FreeBSD, а в случае прокси-сервера SQUID - использовать его механизм delay_pools.

Сервер определяет размер файла, запрошенного пользователем, и если этот размер не превышает установленной величины, то файл загружается на максимально возможной скорости. В случае более объемного файла он передается с заданной ограниченной скоростью. Данный механизм применяется не ко всем пользователям, а лишь к перечисленным в списках ACL (Access Control List - именованная группа объектов, к которым могут применяться различные ограничения), что позволяет очень гибко настраивать приоритеты работы различных групп пользователей.

В то же время, если в данный момент работает только один пользователь, к нему все равно будут применяться ограничения по скорости при загрузке больших файлов. IPFW, в отличие от delay_pools у SQUID, позволяет реализовать динамическое деление канала.

Доступ к ресурсам и другие ограничения

Для IP-схемы возможны ограничения только по IP-адресам серверов и по TCP/UDP-портам. Это вызывает неудобства, поскольку сегодня распространен механизм Virtual Hosts Web-сервера Apache на основе протокола HTTP v1.1, когда один Web-сервер с одним IP-адресом обслуживает множество сайтов с разными DNS-именами.

SQUID же, наоборот, предоставляет очень гибкие механизмы администрирования доступа пользователей к ресурсам Интернета с помощью списков ACL. Это может быть, например, доступ в определенное время, день недели, месяц; разрешение/запрет на копирование определенных типов файлов, разрешение/запрет на обращение к ресурсу, в имени которого содержится некоторое ключевое слово.

Настройка шлюза IPFW

В роли шлюза (gateway) используется компьютер с двумя сетевыми интерфейсами (один подключен к каналу Интернета и имеет реальный IP-адрес, а другой "смотрит" в корпоративную сеть и идентифицируется IP-адресом ее подсети), на котором установлена ОС FreeBSD (http://www.freebsd.org). FreeBSD проста в настройке, надежна, распространяется бесплатно и содержит практически все, что может понадобиться для сетевого сервера масштабов предприятия.

Процесс установки ОС FreeBSD, конфигурирование сетевых интерфейсов, запуск и конфигурирование IPFW, NATD, маршрутизации - в общем, все необходимое для настройки шлюза доступа в Интернет (и по IP, и с помощью прокси-сервера SQUID, кроме настройки самого SQUID) подробно описано в книге М. Эбена и Б. Таймэна "FreeBSD. Энциклопедия пользователя" (Киев: Diasoft, 2003).

Для обоих вариантов организации доступа в Интернет необходимо сконфигурировать ПО IPFW. IPFW фильтрует и подсчитывает IP-пакеты на всех сетевых интерфейсах. Программа также обрабатывает пакеты и на более высоких уровнях: UDP, TCP и ICMP. Кроме того, IPFW участвует в работе NATD. Автор рекомендует при настройке правил ipfw воспользоваться утилитой trafshow для контроля обращений в сеть и из сети по всем интерфейсам с указанием IP-адресов внешних машин, протоколов и портов в реальном времени. Команда

Trafshow -i fxp0 -n

задает отображение пакетов на fxp0-интерфейсе с номерами портов, а команда

Ipfw -a list

отображает правила ipfw, число пакетов и объем трафика (в байтах), прошедших с момента включения сервера или последнего обнуления счетчиков правил.

Внедрение и работа с SQUID

Кэширующий прокси-сервер SQUID (http://www.squid-cache.org) на платформе Unix - это распространяемое бесплатно ПО с открытым кодом. Он легко конфигурируется, хорошо документирован, широко распространен и просто интегрируется с ОС FreeBSD. SQUID позволяет организовать различные типы аутентификации при доступе к Интернету, разграничивает доступ по любому параметру (имени домена, ключевому слову в адресе, протоколу и т. д.) на основе списков ACL.

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

Установка проводится из портов ОС FreeBSD (в версии 4.9, текущая версия 4.10) /usr/ports/www/squid (2.5 версия STABLE3) или /usr/ports/www/squid24 (STABLE7). Нужные опции необходимо раскомментировать в Makefile. Рекомендуемые опции: CONFIGURE_ARGS+= -enable-delay-pools (для включения механизма распределения пропускной способности); CONFIGURE_ARGS+= -enable-err-language=Russian-1251 (для диагностики на русском языке) После установки SQUID необходимо установить саму систему авторизации. Ее исходные тексты содержатся в файлах SQUID: /usr/ports/www/squid24/work/squid-2.4.STABLE7/auth_modules/NCSA Рабочий пример текста squid.conf Icp_port 0 client_netmask 255.255.255.0 authenticate_program /usr/local/squid/bin/ncsa_auth /usr/local/etc/passwd authenticate_children 20 reference_age 2 weeks acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl SSL_ports port 443 563 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 563 # https, snews acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT acl Inet_users proxy_auth "/usr/local/etc/squid_users" delay_pools 1 delay_class 1 2 delay_parameters 1 7500/7500 1875/1875 delay_access 1 allow Inet_users delay_access 1 deny all http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow Inet_users http_access deny all

После установки, конфигурирования, запуска SQUID и его системы авторизации администратору остается только добавление и удаление пользователей. Данные о пользователе достаточно создать лишь в SQUID, так как он не попадает в среду ОС прокси-сервера, и соответственно не надо создавать идентификационные данные пользователя ОС. После изменений в squid.conf или добавления/удаления пользователей SQUID должен перечитать свою конфигурацию без закрытия существующих пользовательских сессий командой

Squid -k reсonfigure.

Создавая пользователя SQUID при помощи ncsa_auth, необходимо прописать login и пароль пользователя в двух файлах конфигурации; в нашем примере это будет выглядеть так:

/usr/local/etc/squid_users /usr/local/etc/passwd

В первый файл просто добавляется имя (login) пользователя с новой строки с помощью текстового редактора. Во втором файле хранятся пароли пользователей (в MD5), и добавлять в этот файл учетную запись можно только с помощью утилиты htpasswd, которая поставляется с Web-сервером Apache.

Необходимо следить за содержанием кэша SQUID и периодически его очищать во избежание переполнения файловой системы - командой squid -Z.

В настройках клиентов в свойствах браузеров и клиентов ICQ необходимо указать IP-адрес прокси-сервера и порт. В нашем примере это IP:192.168.1.8 и порт 3128 (этот порт используется по умолчанию). Если программа ICQ настроена для работы через прокси-сервер, то она использует 443-й, а не 5190-й TCP-порт ICQ-серверов, что также надо учитывать при настройке межсетевых экранов. При использовании SQUID необходимо закрыть для локальных машин возможность обращаться к 80-му TCP-порту Интернет-серверов. Можно вообще разрешить доступ только к порту прокси-сервера, а ко всем остальным, за исключением почтовых, его закрыть, дабы "продвинутые" пользователи не ходили в Интернет в обход SQUID.

С тонкостями настройки SQUID можно познакомиться на сайте http://www.bog.pp.ru/work/squid.html .

Анализ трафика

Для этой цели используется бесплатная программа-анализатор с открытым кодом SARG (). Результат ее работы - HTML-страницы, которые отображают всевозможные статистические срезы данных о работе пользователей в Интернете. Анализируется весь период ведения журнала, поэтому удобнее делать необходимые срезы в конце месяца, а затем очищать журнал SQUID командой access.log.

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

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

Выводы

Мы рассмотрели два варианта организации постоянного подключения корпоративной сети к Интернету.

Для варианта "по IP-адресам компьютеров пользователей с помощью правил IPFW" характерны следующие недостатки. Во-первых, невозможно проверить целесообразность работы пользователя в Интернете, поскольку IPFW подсчитывает только суммарный трафик, по каждому правилу, прописанному для конкретной машины, и не ведет учета посещаемых сайтов. Во-вторых, невозможно провести авторизацию пользователя, работающего в данный момент в Интернете. Это особенно важно, если машину "делят" между собой несколько пользователей. И наконец, существует возможность подмены пользователем IP-адреса.

Кроме того, в случае использования терминального сервера невозможно учитывать трафик различных пользователей, так как все они работают с одного IP-адреса терминального сервера.

Перечисленные недостатки просто отражают ограничения учета и администрирования трафика по IP-адресам и системы учета IPFW. IPFW и не предназначен непосредственно для замеров трафика пользовательских машин, это средство для учета канального трафика.

Полное и законченное решение проблемы предоставляет система, использующая шлюз с ОС FreeBSD, настроенный брандмауэр IPFW и установленный на нем прокси-сервер SQUID с включенной аутентификацией ncsa_auth. Использование кэширующего прокси-сервера в корпоративной сети позволяет сэкономить до 10% на оплате объема месячного трафика и многократно ускорить загрузку повторно посещаемых ресурсов.

Все ПО, применяемое в данном решении, - бесплатное. Расходы на его поддержку минимальны, а как показывает практика, система FreeBSD+SQUID достаточно надежна.

Система SQUID благодаря гибкости настройки и наличию интерфейсов для подключения внешних модулей хорошо масштабируется. Погрешность учета трафика по протоколу HTTP в сравнении с IP, присущая SQUID, не принципиальна; гораздо важнее, что при этом можно организовать достоверный количественный и качественный мониторинг работы пользователей в Интернете по протоколам HTTP, HTTPS и FTP и разграничить права и приоритеты доступа.

Прокси-сервер способен функционировать на достаточно маломощной машине, например, с процессором Celeron частотой 1 ГГц, 128 Мбайт памяти и жестким диском 20 Гбайт (такая конфигурация в данный момент работает на нашем предприятии, обслуживая 30 пользователей), а роль шлюза при доступе по IP (FreeBSD, IPFW, NATD) может выполнять компьютер на базе Pentium 166 МГц со 128 Мбайт памяти.