Использование аутентификации в squidGuard

·

·

Пер. с англ., источник — http://www.squidguard.org/Doc/authentication.html

Иногда удобно разрешить разным пользователям различный тип доступа. SquidGuard имеет возможность указать, основываясь на имени пользователя, к каким ресурсам этот пользователь может иметь доступ.
Имеется два различных способа, как установить аутентификацию пользователя: на основе имени, предоставленном прокси-сервером squid, или используя роли LDAP (это подразумевает, что либо вы используете squidGuard 1.2.1 и выше, или имеете squidGuard, пропатченный вами с помощью LDAP-патчей Криса Фрея.

1. Аутентификация с помощью имен пользователей прокси-сервера squid

Начнем по порядку: чтобы сделать это, вы должны настроить ваш squid для аутентификации ваших пользователей. Простой способ добавить пользовательскую аутентификацию — использование старой утилиты ncsa_auth. Добавляя следующие три строки в ваш squid.conf, вы можете включить аутентификацию:

auth_param basic program /usr/libexec/squid/ncsa_auth \ /etc/squid/squid.passwd
acl password proxy_auth REQUIRED
http_access allow password

Пожалуйста, обратите внимание, что путь к вашему файлу паролей squid и к nsca_auth может отличаться в вашей системе. Тем не менее, вы можете изменить путь к вашему собственному файлу паролей на ваш собственный путь; nsca_auth имеет фиксированное месторасположение (используйте find или locate, чтобы получить корректный путь).
Имеются также другие значения аутентификации в squid. Дополнительные подробности смотрите на сайте прокси-сервера squid.
Чтобы предоставить доступ на основании пользовательских имен, у вас есть два варианта: вы можете непосредственно перечислить пользователей в тэге user вашего файла squidGuard.conf, или вы можете ввести имя файла (рекомендуется, если имеем дело с множеством имен) и использовать тэг userlist. В обоих случаях вы должны включить определения пользователя внутри определенного acl. Следующие два примера показывают, как использовать тэги user и userlist:

src department1 {
user maria josef susanna micheal george1
}

В этом примере пять пользователей группируются в источник  department1. Это источник используется, чтобы предоставить или запретить доступ определенным категориям (смотрите определение acl после следующего примера).
Вы можете использовать числа в именах пользователей. К сожалению, в текущее время есть баг squidGuard, выдающий ошибки при использовании имен пользователей, состоящих полностью из чисел. В этом случае используйте тэг userlist (см. след. пример), чтобы урегулировать пользовательский доступ:

src department1 {
userlist dep1users
}

В этом примере конфигурация squidGuard указывает на файл, называемый здесь dep1users, где могут быть найдены пользователи. Расположение файла со списком пользователей связано с путем, который вы определили для параметра dbhome.
Файл со списком пользователей — это обычный текстовый файл в следующем формате:

user1
user2
user3
user4
user5

и т.д.

Когда вы уже определили ваших пользователей, вы должны настроить, какой(ая) пользователь (группа) имеет доступ к какому назначению (destination). Это делается в части acl вашего конфигурационного файла squidGuard.conf:

acl {
department1 {
pass !porn !hacking !warez all
redirect http://localhost/cgi/blocked?clientaddr=%a&clientuser=%i&clientgroup=%s&url=%u
}
default {
pass white none
redirect http://localhost/cgi/blocked?clientaddr=%a&clientuser=%i&clientgroup=%s&url=%u
}
}

В этом примере пользователь department1 может иметь доступ ко всем веб-сайтам, кроме тех, которые перечислены в категориях porn, hacking и warez. Все остальным пользователям доступ разрешен только к тем ресурсам, которые перечислены в категории white (белый список). Конечно же, вы можете определить назначения до установки acl. 🙂

2. Использование LDAP.

Точно так же, как в примерах до этого, вы должны определить окружение src, где может быть найдена пользовательская информация. Вдобавок вы должны определить некоторые специфичные тэги LDAP: вы должны назвать верхний уровень дерева каталога LDAP и пароль для доступа к пользовательской информации (если только вы не используете анонимный режим (anonymous bind), который с точки зрения безопасности всегда не рекомендуется).
Существуют следующие LDAP-специфические тэги:

  • ldapusersearch — Это ключевое слово входит в конфигурационный блок src и определяет URL LDAP для поиска неизвестного имени пользователя. Вы можете определить множество URL для LDAP в блоке источника src. Используйте ‘%s‘, чтобы определить имя пользователя в вашем URL для LDAP. Если поиск возвратит запись, пользователь считается «найденным», иначе проверяется следующий URL в блоке src. SquidGuard кэширует состояние «найден» для каждого поиска, даже когда имя пользователя не найдено. Кэш действителен в течение времени, которое задано параметром ldapcachetime (в сек.).

 

  • ldapcachetime — это глобальное ключевое слово определяет число секунд для кэширования результатов поиска LDAP до соединения с сервером LDAP снова. Это ключевое слово глобально и должно находиться вне любых блоков src/dest/rule. Делая это значение достаточно низким, можно смоделировать сходную с реальностью группировку в LDAP без перезапуска squidguard. Рекомендованное значение: 300
  • ldapbinddn — Глобальное ключевое слово, определяющее DN (Distinguished Name, уникальное имя), для того чтобы связаться с сервером LDAP.
  • ldapbindpass — Пароль для связи с LDAP-сервером. Это глобальное ключевое слово.
  • ldapprotover — Описывает версию протокола LDAP. Это глобальное ключевое слово. Используйте его, чтобы заставить squidGuard соединиться с LDAP-сервером, который имеет определенную версию протокола. Если вы не можете использовать определенную версию протокола, squidGuard перейдет в аварийный режим. Допустимые параметры: 2 или 3.

Примерная конфигурация:

ldapbinddn cn=root, dc=example, dc=com
ldapbindpass myultrasecretpassword

# ldap cache time in seconds
ldapcachetime 300

src my_users {
ldapusersearch ldap://ldap.example.com/cn=squidguardusers,ou=groups,dc=example,dc=com?memberUid?sub?(&(objectclass=posixGroup)(memberUid=%s))
}

Когда вы используете LDAP для аутентификации, убедитесь что параметры вашей строки ldapusersearch соответствуют пользовательским настройкам на вашем сервере LDAP. Если имена ваших пользователей не сохранены в «MemberUid«, то «uid» вы должны соответственно адаптировать в вашей строке ldapusersearch . То же самое справедливо для значений, которые вы вводите для «objectclass«. Вы, возможно, имеете что-то наподобие «Person» или «InetOrgPerson» вместо этого.
Если значение ldapusersearch не совпадает с вашими конфигурационными настройками, поиск завершится с ошибкой.

Добавить комментарий

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

Закончите арифметическое действие * Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.