Linux прокси сервер с веб интерфейсом

Бесплатный прокси-сервер для предприятия с доменной аутентификацией

pfSense+Squid с фильтрацией https + Технология единого входа (SSO) с фильтрацией по группам Active Directory

Краткая предыстория

На предприятии возникла необходимость во внедрении прокси-сервера с возможностью фильтрации доступа к сайтам(в том числе https) по группам из AD, чтобы пользователи не вводили никаких дополнительных паролей, а администрировать можно было с веб интерфейса. Неплохая заявочка, не правда ли?

Правильным вариантом ответа было бы купить такие решения как Kerio Control или UserGate, но как всегда денег нет, а потребность есть.

Тут то к нам и приходит на выручку старый добрый Squid, но опять же — где взять веб интерфейс? SAMS2? Морально устарел. Тут то и приходит на выручку pfSense.

Описание

В данной статье будет описан способ настройки прокси-сервера Squid.
Для авторизации пользователей будет использоваться Kerberos.
Для фильтрации по доменным группам будет использоваться SquidGuard.

Для мониторинга будет использован Lightsquid, sqstat и внутренние системы мониторинга pfSense.
Также будет решена частая проблема, связанная с внедрением технологии единого входа (SSO), а именно приложения, пытающиеся ходить в интернет под учеткой компа\своей системной учеткой.

Подготовка к установке Squid

За основу будет взят pfSense, Инструкция по установке.

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

Перед началом установки Squid необходимо настроить DNS сервера в pfsense, сделать для него запись A и PTR записи на нашем DNS сервере и настроить NTP так, чтобы время не отличалось от времени на контроллере домена.

А в вашей сети предоставить возможность WAN интерфейсу pfSense ходить в интернет, а пользователям в локальной сети подключаться на LAN интерфейс, в том числе по порту 7445 и 3128 (в моем случае 8080).

Всё готово? С доменом связь по LDAP для авторизации на pfSense установлена и время синхронизировано? Отлично. Пора приступать к основному процессу.

Установка и предварительная настройка

Squid, SquidGuard и LightSquid установим из менеджера пакетов pfSense в разделе «Система/Менеджер пакетов».

После успешной установки переходим в «Сервисы/Squid Proxy server/» и в первую очередь во вкладке Local Cache настраиваем кеширование, я выставил все по 0, т.к. не вижу особого смысла кешировать сайты, с этим и браузеры прекрасно справляются. После настройки нажимаем клавишу «Сохранить» внизу экрана и это даст нам возможность производить основные настройки прокси.

Основные настройки приводим к следующему виду:

Порт по умолчанию 3128, но я предпочитаю использовать 8080.

Выбранные параметры во вкладке Proxy Interface определяют какие интерфейсы будет слушать наш прокси сервер. Так как этот межсетевой экран построен таким образом, что в интернет он смотрит WAN интерфейсом, даже при том что LAN и WAN могут быть в одной локальной подсети, рекомендую для прокси использовать именно LAN.

Лупбек нужен для работы sqstat.

Ниже вы найдете настройки Transparent (прозрачного) прокси, а также SSL Filter, но они нам не нужны, наш прокси будет не прозрачным, а для фильтрации https мы не будем заниматься подменой сертификата(у нас ведь документооборот, банк-клиенты и тд), а просто посмотрим на рукопожатие.

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

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

После этого всего формируем файл ключей для кербероса, на контроллере домена открываем командную строку с правами администратора и вводим:

Где указываем свой FQDN pfSense, обязательно соблюдая регистр, в параметр mapuser вводим нашу доменную учетную запись и её пароль, а в crypto выбираем способ шифрования, я использовал rc4 для работы и в поле -out выбираем куда отправим наш готовый файл ключей.
После успешного создания файла ключей отправим его на наш pfSense, я использовал для этого Far, но также можно сделать этот как командами, так и putty или через веб интерфейс pfSense в разделе «Диагностика\Командная строка».

Теперь мы можем отредактировать\создать /etc/krb5.conf

где /etc/krb5.keytab это созданный нами файл ключей.

Обязательно проверьте работу кербероса с помощью kinit, если не работает — дальше нет смысла читать.

Настройка аутентификации Squid и списка доступа без аутентификации

Успешно настроив керберос прикрутим его к нашему Squid`у.

Для этого перейдите в Сервисы\Squid Proxy Server и в основных настройках опуститесь в самый низ, там найдем кнопочку «Расширенные настройки».

В поле Custom Options (Before Auth) введем:

uде auth_param negotiate program /usr/local/libexec/squid/negotiate_kerberos_auth — выбирает необходимый нам хелпер керберос аутентификации.

Ключ -s с значением GSS_C_NO_NAME — определяет использование любой учетной записи из файла ключа.

Ключ -k с значением /usr/local/etc/squid/squid.keytab — определяет использовать именно этот кейтаб файл. В моем случае это тот же сформированный нами кейтаб файл, который я скопировал в директорию /usr/local/etc/squid/ и переименовал, потому что с той директорией сквид дружить не хотел, видимо прав не хватало.

Ключ -t с значением -t none — отключает цикличные запросы к контроллеру домена, что сильно снижает нагрузку на него если у вас больше 50 пользователей.
На время теста также можно добавить ключ -d — т.е диагностика, больше логов будет выводиться.
auth_param negotiate children 1000 — определяет сколько одновременных процессов авторизации может быть запущено
auth_param negotiate keep_alive on — не дает разорвать связь во время опроса цепочки авторизации
acl auth proxy_auth REQUIRED — создает и требует список контроля доступа, включающий в себя пользователей, прошедших авторизацию
acl nonauth dstdomain «/etc/squid/nonauth.txt» — сообщаем сквиду о списке доступа nonauth в котором содержатся домены назначения, к которым всегда будет разрешен доступ всем. Сам файл создаем, а внутрь него вписываем домены в формате

Whatsapp не зря используется как пример — он очень привередлив к прокси с аутентификацией и не будет работать если его не разрешить до аутентификации.
http_access allow nonauth — разрешаем доступ к данному списку всем
http_access deny !auth — запрещаем доступ неавторизованным пользователям к остальным сайтам
http_access allow auth — разрешаем доступ авторизированным пользователям.
Всё, сам сквид у вас настроен, теперь самое время приступить к фильтрации по группам.

Настройка SquidGuard

Переходим в Сервисы\SquidGuard Proxy Filter.

В LDAP Options вводим данные нашей учетной записи, используемой для керберос аутентификации, но в следующем формате:

Если есть пробелы и\или не латинские символы всю эту запись стоит заключить в одинарные или двойные кавычки:

Далее обязательно ставим эти галочки:

Чтобы отрезать ненужные DOMAIN\pfsense DOMAIN.LOCALк которым вся система очень чувствительна.

Теперь переходим в Group Acl и привязываем наши доменные группы доступа, я использую простые наименования в духе group_0, group_1 и тд до 3, где 3 — доступ только в белый список, а 0 — можно всё.

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

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

LightSquid и sqstat

Если в процессе настройки мы выбрали лупбек в настройках сквида и открыли возможность заходить на 7445 в фаерволле как в нашей сети, так и на самом pfSense, то при переходе в Диагностика\Squid Proxy Reports мы без проблем сможем открыть и sqstat и Lighsquid, для последнего нужно будет там же придумать логин и пароль, а также есть возможность выбрать оформление.

Завершение

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

Надеюсь данная статья поможет кому-нибудь решить достаточно актуальную для средних и крупных предприятий задачу.

Источник

SQUID для ленивых. Облегчаем себе жизнь

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

Ну, давайте обсудим с чего мы начинаем, у нас есть сервер в моем случае это свежеустановленная Ubuntu Server с выбранными параметрами LAMP и SSH (специально с целью написания статьи):

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

Здесь интернет будет идти от eth1, локальная сеть, т.е. я буду находится со стороны eth0.
Естественно рекомендуется, провести:

Следующим шагом мы должны поставить дополнительные пакеты для нашего прокси сервера, как наверное Вы догадались мы будем использовать связку SQUID+SAMS, но настраивать будем типичный случай, авторизация по IP, и для облегчения себе жизни заворот всех пользователей на порт прокси сервера. Эту связку потом можно будет с легкостью настроить на авторизацию по логин/паролю, и даже связать с AD.
Необходимыми пакетами для нашего случая мы установим так:

Если вдруг будет мало доустановим еще. Следующим шагом будет скачивание и установка самого SAMS, скачиваем стабильную версию 1.0.5, есть еще SAMS 2.0, но как-то попробовал, еще слишком много багов было.

Далее, распаковываем и устанавливаем его:

После этого в принципе не должно получится ошибок, и можно смело продолжать, если есть какие-то ошибки, значит следует вчитаться, и доустановить то чего не хватает.
Далее копируем скрипт запуска sams, к нам на сервер

Далее чуть-чуть настроим MySQL. Нужно загрузить таблицы, и организовать доступ к ним:

Далее чуть-чуть правим файл, /etc/sams.conf:
MYSQLPASSWORD=maxim

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

Теперь настраиваем обработку лога access.log
Открываем crontab, лучше это делать с помощью crontab -e, и добавляем туда следующую строчку:
*/1 * * * * /usr/local/bin/sams

Далее создадим директории для кэша сквида:
root@testgateway:

/sams-1.0.5/mysql# squid -z
2011/10/13 12:40:12| Creating Swap Directories

и стартуем squid.
root@testgateway:

/sams-1.0.5/mysql# /etc/init.d/squid start

Если картина идентична, то значит все запустилось хорошо.
Далее идем настраивать наш SAMS, это уже делается через веб-интерфейс, вбиваем в браузере адрес нашего прокси, у нас он был 192.168.0.237/sams, и видим страницу приглашения ввод и пользователя и пароля.
Но прежде чем мы это сделаем мы должны исправить небольшой баг этой системы, а именно в связи с выходом PHP5.3, немного некорректно отображаются страницы настройки, вернее совсем не отображаются. Но это операция не сложная, просто правим два файла:
/usr/local/share/sams/src/configtray.php
/usr/local/share/sams/src/webconfigtray.php
переименовываем GetHostName в GetHostNameSams и все заработало.
Дальше я буду на примере маленьких скриншотов показывать, что и где нужно править, чтобы все работало, как нам надо. Приглашение, по умолчанию логин: Admin, пароль: qwerty

Следующий шаг, настройка веб-интерфейса, выставляем следующие параметры:

Окно администрирование SAMS не влезло в ширину экрана, поэтому опишу текстом, авторизацию устанавливаем IP, файл перенаправления запроса 192.168.0.237/sams/icon/classic/blank.gif, путь к каталогу, где лежат файлы запрета запроса 192.168.0.237/sams/messages, редиректор встроенный SAMS, и последнее сохранять данные о трафике в базе за последние 12 месяцев.
Далее переходим к настройке шаблонов, удаляем все, чтобы нам ничего не мешало и создаем новый.

Далее добавляем пользователя и связываем его c нашим шаблоном

Далее запускаем демон samsd: /etc/init.d/samsd start. И реконфигурируем SQUID.
После этого, если пользователю прописать прокси в браузере все начинает отлично работать, но так как нам это не удобно будет делать на всех пользователях, так что применим классическую админскую хитрость, заворот HTTP трафика на порт прокси сервера.

iptables -t nat -A PREROUTING -p tcp —dport 80 -j REDIRECT —to-ports 3128

Вот так вот у нас получился прокси, с удобным веб-интерфейсом, возможно кто-то меня обвинит в плагиате, мол уже 100 раз это все было, но сразу хочется отметить, что как я и сказал в самом начале статьи, этот вариант настройки прокси для ленивых, т.к. практически все вкусности SQUID, такие как ограничения по трафику, создание списков доступа, разрешенных доменов, запрет на скачивание, можно получить из веб-настройки. А также мы легко получаем систему просмотра статистики, которой может воспользоваться любой пользователь Вашей организации, зайдя на страничку под своим логином. Конечно остается сложность с учетом трафика торрентов, почты и другого не 80 порта, и на это тоже есть свое решение, которое очень хорошо впишется в общую картину.
Если буду формироваться вопросы, милости прошу, обсудим, все остальные тонкости настройки

Источник