главная - Статьи - Microsoft Windows - Прокси-сервер 3proxy

Управление службами 3proxy

Как запустить конкретную службу (HTTP, SOCKS и т.д)
Как повесить службу на определенный интерфейс или порт
Ограничить доступ к службе 3proxy

Как запустить конкретную службу (HTTP, SOCKS и т.д)

3proxy поставляется в двух вариантах: как набор отдельных модулей (proxy, socks, pop3p, tcppm, udppm) и как универсальный прокси-сервер (3proxy). Универсальный прокси сервер - это законченная программа, которой не требуются отдельные модули.
Отдельный модуль управляется только из командной строки. Поэтому для отдельного модуля не поддерживаются многие функции, такие как управление доступом и ротация журнала. Запуск модуля осуществляется из командной строки. Например,

$/sbin/socks -l/var/log/socks.log -i127.0.0.1

запускает SOCKS на порту 127.0.0.1:1080 с ведением журнала /var/log/socks.log.

Справку по опциям командной строки можно получить запустив модуль с ключом -?.

Если используется 3proxy, то запускаемые службы указываются в файле 3proxy.cfg. Файл 3proxy.cfg просматривается 3proxy построчно, каждая строка рассматривается как управляющая команда. Синтаксис команд описан в 3proxy.cfg.sample. Например,

log /var/log/3proxy.log D rotate 30 internal 127.0.0.1 external 192.168.1.1 proxy socks pop3p -l/var/log/pop3proxy

запускает 3 службы - PROXY, SOCKS и POP3 Proxy. Каждая слушает на интерфейсе 127.0.0.1 порт по-умолчанию (3128 для proxy, 1080 для socks и 110 для pop3p). Журналы всех служб кроме pop3p ведутся в файле /var/log/3proxy.log, который ежедневно меняется. Хранятся 30 последних файлов. Для pop3p ведется отдельный журнал /var/log/pop3proxy (см. Как настроить ведение журнала).

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

Опция -i позволяет указать внутренний интерфейс, -p - порт (пробелы в опциях не допускаются). Например, чтобы служба proxy висела на порту 8080 интерфейсов 192.168.1.1 и 192.168.2.1 необходимо дать команды

proxy -p8080 -i192.168.1.1 proxy -p8080 -i192.168.2.1

Ограничить доступ к службе 3proxy

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

Указание внешнего интерфейса (т.е. IP, с которого сервер будет устанавливать внешние соединения) так же является полезным. Для этого служит команда external и ключ -e соответственно. Для универсального прокси возможна дополнительная авторизация доступа с помощью имени/пароля, NetBIOS имени пользователя и по спискам доступа (по IP клиента, IP и порту назначения, см. Как ограничить доступ пользователей к ресурсам). Тип авторизации устанавливается командой auth в файле конфигурации.

auth none

Отсутствие какой-либо авторизации. Списки доступа не проверяются.

auth iponly

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

auth nbname

Перед проверкой по списком доступа будет произведена попытка получить NetBIOS имя клиента. Для этого используется NetBIOS код службы messager (0x03). Если имя определить не удалось (служба messager для Windows NT/2000/XP или WinPopUP для 95/98/ME не запущена), то имя будет считаться пустым. Далее следует проверка по спискам доступа. Данный тип авторизации не зависит от платформы сервера (т.е. прокси сервер, запущенный под Unix, сможет определять NetBIOS имена). Его рекомендуется использовать в однородных сетях, где у всех клиентов установлена Windows NT/2000/XP и пользователи не имеют доступа к привелегированным учетным записям. Этот вид авторизации не является надежным.

auth strong

Проверяется имя и пароль, переданные пользователем при подключении к прокси. Данный вид авторизации работает только с proxy и socks. Необходимо задание списка пользователей (см Как создать список пользователей). Соединения от неизвестных пользователей не принимаются. После проверки имени пользвоателя и пароля происходит проверка списков доступа.

Для разных служб можно установить различные типы авторизации, например,

auth none pop3p auth iponly proxy auth strong socks

не накладывает ограничений на использование POP3 Proxy, производит проверку по спискам доступа для пользователей HTTP Proxy и требует авторизации с именем и паролем для SOCKS.

С версии 0.6 возможно использвоать двойную авторизацию, например,

auth iponly strong allow * * 192.168.0.0/16 allow user1,user2 proxy

будет использовать авторизацию только в том случае, если не удалось пропустить пользователя с авторизаций iponly, т.е. для доступа к ресурсам 192.168.0.0/16 авторизация не требуется.

С версии 0.6 так же можно использвоать кэширование авторизации (имени пользователя) с целью повышения производительности. Использовать кэширование для strong практически не имеет смысла, она полезно для nbname и авторизации через внешние плагины, типа WindowsAuthentication. Кэширование настраивается командой authcache с двумя параметрами - типом кэширования и временем, на которое кэшируется пароль. Возможные типы: ip - после успешной авторизации в течение времени кэширования все запросы пришедшие с того же адреса считаются запросами от того же пользователя, name - после успешной авторизации от пользователя с тем же именем требуют указания имени, но реально аутентификации не производится, ip,name - запрос должен придти от того же IP и с тем же именем. user,password - имя и пароль пользователя сверяются с кэшированными. Возможны и другие сочетания. Для авторизации должен использоваться специальный метод авторизации - cache. Пример:

authcache ip 60 auth cache strong windows proxy -n

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

***
Источник: SECURITYVULNS.RU

Авторизуйтесь для добавления комментариев!