Linux proxy with authentication

Авторизация прокси по NTLM в Linux

В корпоративной среде основанной на продуктах Microsoft, достаточно часто можно встретить использование прокси-сервера встроенного в ISA Server/Forefront TMG. Как правило, авторизация пользователей на таком прокси производится c помощью NTLM.

Если на сегодняшний день в Windows большинство программ имеют встроенную поддержку NTLM, то Linux этим похвастаться не может. Связи с чем, в данной статье речь пойдет о механизме использования прокси с NTLM аутентификацией в Linux.

Для этого мы будем использовать cntlm — небольшой, быстрый промежуточный HTTP-прокси, который возьмет функцию NTLM аутентификации на себя. Его задача пропускать через себя запросы от программ к прокси-серверу.

Установка cntlm

Чтобы установить cntlm в Debian/Ubuntu выполните следующую команду:

Для установки cntlm в CentOS/RHEL необходимо подключить репозиторий Epel. После чего выполнить команду:

Настройка cntlm

Откройте конфигурационный файл:

Установите имя пользователя, домен, адрес и порт прокси-сервера, локальный интерфейс и порт на котором cntlm будет принимать входящие соединения:

Выясним какой тип авторизации использует наш прокси-сервер:

Теперь когда мы знаем тип используемой аутентификации и хеш нашего пароля. Необходимо добавить в сntlm.conf следующие параметры:

Для использования cntlm в качестве локального прокси в Linux, нужно настроить переменные окружения http_proxy , https_proxy , ftp_proxy :

Источник

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

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 машинами это решило проблему и позволило сэкономить на покупке прокси.

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

Источник

Authenticate proxy with nginx

Estimated reading time: 5 minutes

This page contains information about hosting your own registry using the open source Docker Registry. For information about Docker Hub, which offers a hosted registry with additional features such as teams, organizations, web hooks, automated builds, etc, see Docker Hub.

Use-case

People already relying on a nginx proxy to authenticate their users to other services might want to leverage it and have Registry communications tunneled through the same pipeline.

Usually, that includes enterprise setups using LDAP/AD on the backend and a SSO mechanism fronting their internal http portal.

Alternatives

If you just want authentication for your registry, and are happy maintaining users access separately, you should really consider sticking with the native basic auth registry feature.

Solution

With the method presented here, you implement basic authentication for docker engines in a reverse proxy that sits in front of your registry.

While we use a simple htpasswd file as an example, any other nginx authentication backend should be fairly easy to implement once you are done with the example.

We also implement push restriction (to a limited user group) for the sake of the example. Again, you should modify this to fit your mileage.

Gotchas

While this model gives you the ability to use whatever authentication backend you want through the secondary authentication mechanism implemented inside your proxy, it also requires that you move TLS termination from the Registry to the proxy itself.

Note: Docker does not recommend binding your registry to localhost:5000 without authentication. This creates a potential loophole in your Docker Registry security. As a result, anyone who can log on to the server where your Docker Registry is running can push images without authentication.

Furthermore, introducing an extra http layer in your communication pipeline makes it more complex to deploy, maintain, and debug. Make sure the extra complexity is required.

For instance, Amazon’s Elastic Load Balancer (ELB) in HTTPS mode already sets the following client header:

So if you have an Nginx instance sitting behind it, remove these lines from the example config below:

Otherwise Nginx resets the ELB’s values, and the requests are not routed properly. For more information, see #970.

Setting things up

Review the requirements, then follow these steps.

Create the required directories

Create the main nginx configuration. Paste this code block into a new file called auth/nginx.conf :

Create a password file auth/nginx.htpasswd for “testuser” and “testpassword”.

Note: If you do not want to use bcrypt , you can omit the -B parameter.

Copy your certificate files to the auth/ directory.

Create the compose file. Paste the following YAML into a new file called docker-compose.yml .

Starting and stopping

Now, start your stack:

Login with a “push” authorized user (using testuser and testpassword ), then tag and push your first image:

Источник

Установка и использование 3proxy на Ubuntu

Настройка брандмауэра

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

а) если используем Iptables.

iptables -I INPUT 1 -p tcp —dport 3128 -j ACCEPT

* если система вернет ошибку при вводе команды для сохранения правил, устанавливаем пакет командой apt-get install iptables-persistent.

б) если у нас firewalld.

firewall-cmd —permanent —add-port=3128/tcp

* 3128 — порт по умолчанию, по которому работает 3proxy в режиме прокси;

Установка и запуск 3proxy

3proxy отсутствует в репозиториях Ubuntu, поэтому для установки сначала необходимо скачать его исходник.

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

apt-get install build-essential

Переходим на официальную страницу загрузки 3proxy и копируем ссылку на версию пакета для Linux:

. используя ссылку, скачиваем пакет:

* в моем случае будет скачена версия 0.9.3.

Распакуем скачанный архив:

tar xzf 0.9.3.tar.gz

Переходим в распакованный каталог:

Запускаем компиляцию 3proxy:

make -f Makefile.Linux

Создаем системную учетную запись:

adduser —system —disabled-login —no-create-home —group proxy3

Создаем каталоги и копируем файл 3proxy в /usr/bin:

mkdir -p /var/log/3proxy

cp bin/3proxy /usr/bin/

Задаем права на созданные каталоги:

chown proxy3:proxy3 -R /etc/3proxy

chown proxy3:proxy3 /usr/bin/3proxy

chown proxy3:proxy3 /var/log/3proxy

Смотрим uid и gid созданной учетной записи:

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

uid=109(proxy3) gid=113(proxy3) groups=113(proxy3)

* где 109 — идентификатор пользователя; 113 — идентификатор для группы.

Создаем конфигурационный файл:

setuid 109
setgid 113

nserver 77.88.8.8
nserver 8.8.8.8

nscache 65536
timeouts 1 5 30 60 180 1800 15 60

external 111.111.111.111
internal 111.111.111.111

log /var/log/3proxy/3proxy.log D
logformat «- +_L%t.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T»
rotate 30

allow * * * 80-88,8080-8088 HTTP
allow * * * 443,8443 HTTPS

* необходимо обратить внимание на настройки setuid и setgid — это должны быть значения для созданной нами учетной записи; external и internal — внешний и внутренний интерфейсы (если наш прокси работает на одном адресе, то IP-адреса должны совпадать).

Настройка браузера

Проверяем работоспособность нашего 3proxy. Для этого настраиваем браузер для работы через прокси-сервер, например, Mozilla Firefox:

. пробуем открыть сайты.

Настройка автозапуска

Для автозагрузки 3proxy настроим его как сервис. Создаем файл в systemd:

[Unit]
Description=3proxy Proxy Server

[Service]
Type=simple
ExecStart=/usr/bin/3proxy /etc/3proxy/3proxy.cfg
ExecStop=/bin/kill `/usr/bin/pgrep -u proxy3`
RemainAfterExit=yes
Restart=on-failure

Обновляем конфигурацию systemd:

Разрешаем запуск сервиса и стартуем его:

systemctl enable 3proxy

systemctl start 3proxy

Настройка аутентификации

Для редактирования настроек открываем конфигурационный файл:

Добавляем опции users и добавляем пользователей:

users 3APA3A:CL:3apa3a «test:CR:$1$qwer$CHFTUFGqkjue9HyhcMHEe1»
users dmosk1:CL:password
users «dmosk2:CR:$1$UsbY5l$ufEATFfFVL3xZieuMtmqC0»

* в данном примере мы добавили 3-х пользователей: 3APA3A с паролем 3apa3a, dmosk1 с открытым паролем password и dmosk2 с паролем dmosk2 в виде md5 и солью UsbY5l (Для получения хэша пароля можно воспользоваться командой openssl passwd -1 -salt UsbY5l, где в качестве соли можно использовать любую комбинацию).
* обратите внимание, при использовании знака $, строчка пишется в кавычках.

* возможные типы паролей:

• CL — текстовый пароль
• CR — зашифрованный пароль (md5)
• NT — пароль в формате NT.

Чтобы включить запрос логина, необходимо поменять значение для опции auth на strong:

* возможные варианты для auth:

• none — без авторизации.
• iponly — авторизация по IP-адресу клиента.
• nbname — по Netbios имени.
• strong — по логину и паролю.

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

auth nbname strong

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

systemctl restart 3proxy

SOCKS

Для прозрачного прохождения пакетов через прокси можно настроить SOCKS5. В конфигурационном файле добавляем:

* запускаем socks на порту 1080.

socks -p8083 -i192.168.1.23 -e111.111.111.111

* запускаем socks на порту 8083; внутренний интерфейс — 192.168.1.23, внешний — 111.111.111.111.

После перезапускаем сервис:

systemctl restart 3proxy

Настройка анонимности

Для обеспечения полной анонимности при использовании прокси-сервера, делаем дополнительные настройки.

1. Меняем порты, которые используются по умолчанию — 3128, 1080. Данные порты известны, как порты для прокси. Открываем конфигурационный файл 3proxy:

socks -p1088
proxy -n -p3111

* в данном примере мы укажем серверу работать на портах 3111 и 1088.

После перезапускаем сервис:

systemctl restart 3proxy

2. Необходимо, чтобы время на сервере совпадало с временем на компьютере.

На стороне сервера необходимо задать часовой пояс, например, если наш прокси находится в Германии, вводим:

timedatectl set-timezone Europe/Berlin

На стороне клиента либо меняем часовой пояс в системе, либо устанавливаем плагин для браузера, например, для Mozilla Firefox и меняем часовой пояс уже в нем.

3. Отключение icmp. По времени ответа на ping можно определить отдаленноесть клиента от прокси. Чтобы проверку нельзя было выполнить, отключаем на сервере icmp. Для этого создаем файл:

И применяем настройки:

sysctl -p /etc/sysctl.d/icmp.conf

4. Проверяем настройки.

Открываем браузер, который работает через прокси и переходим на страницу 2ip.ru/privacy — кликаем по Проверить:

Будет выполнена проверка анонимности нашего сервера.

Дополнительные настройки

Настройки, которые могут не понадобиться. Но они позволят настроить дополнительные возможности прокси-сервера.

Настройка портов и прокси-интерфейсов

При необходимости, можно настроить 3proxy на использование разных интерфейсов на разных портах:

proxy -n -a -p3128 -i192.168.0.23 -e222.222.222.222
proxy -n -a -p8080 -i192.168.1.23 -e111.111.111.111

* 3proxy будет слушать на порту 3128 с внутреннего интерфейса 192.168.0.23 и направлять пакеты в сеть Интернет через внешний интерфейс 222.222.222.222, а также, на порту 8080 для внутреннего и внешнего интерфейсов 192.168.1.23 и 111.111.111.111 соответственно.
* не забываем также настраивать брандмауэр (вначале инструкции мы открывали только 3128 порт).

systemctl restart 3proxy

Ограничение пропускной способности

При необходимости, можно ограничить скорость.

bandlimin 1000000 user1,user3
bandlimin 5000000 user2,user4

* в данном примере пользователям user1 и user3 установлено ограничение в 1000000 бит/сек (1 мбит); для user2 и user4 — 5 мбит/сек.

systemctl restart 3proxy

Ограничения доступа

Можно ограничить доступ и разрешить только для определенных портов, сетей и пользователей.

• userlist — список пользователей через запятую.
• sourcelist — сети клиентов через запятую.
• targetlist — сети назначения через запятую.
• targetportlist — порты назначения через запятую.
• commandlist — команды, к которым применяется правило.
• weekdays — в какие дни недели работает правило. 0 — 6 — Пн — Вс, 7 — тоже Вс.
• timeperiodslist — время, когда работает правило. Указываются диапазоны.

allow * * * 80 HTTP
allow * * * 443,8443 HTTPS
allow * * * 21 FTP

* в данном примере пользователям user1 и user3 установлено ограничение в 1000000 бит/сек (1 мбит); для user2 и user4 — 5 мбит/сек.

Также, ограничить доступ можно по количеству одновременных соединений для каждой службы:

maxconn 700
proxy -n -a -p3128 -i192.168.0.23 -e222.222.222.222
proxy -n -a -p8080 -i192.168.1.23 -e111.111.111.111

* таким образом, мы установим 700 максимальных соединений для прокси на порту 3128 и 700 — для proxy на порту 8080.

Источник