Какие схемы аутентификации используются в squid

�� Proxy Authentication

There are six major flavours of authentication available in the HTTP world at this moment:

• Basic — been around since the very beginning
• NTLM — Microsoft’s first attempt at single-sign-on for LAN environments
• Digest — w3c’s attempt at having a secure authentication system
• Negotiate (aka SPNEGO) — Microsoft’s second attempt at single-sign-on.
• OAuth — IETF attempt at single-sign-on
• OAuth 2.0 (aka Bearer) — IETF second attempt at single-sign-on

Squid-2.6 and later support Basic, NTLM (SMB LM, v1 and v2), Digest, and Negotiate (Kerberos and/or NTLM flavours).

�� How does Proxy Authentication work in Squid?

Users will be authenticated if squid is configured to use proxy_auth ACLs (see next question).

Browsers send the user’s authentication credentials in the HTTP Authorization: request header.

If Squid gets a request and the http_access rule list gets to a proxy_auth ACL or an external ACL (external_acl_type) with %LOGIN parameter, Squid looks for the Authorization: header. If the header is present, Squid decodes it and extracts a user credentials.

If the header is missing, Squid returns an HTTP reply with status 407 (Proxy Authentication Required). The user agent (browser) receives the 407 reply and then attempts to locate the users credentials. Sometimes this means a background lookup, sometimes a popup prompt for the user to enter a name and password. The name and password are encoded, and sent in the Authorization header for subsequent requests to the proxy.

NOTE: The name and password are encoded using “base64” (See section 11.1 of RFC 2616). However, base64 is a binary-to-text encoding only, it does NOT encrypt the information it encodes. This means that the username and password are essentially “cleartext” between the browser and the proxy. Therefore, you probably should not use the same username and password that you would use for your account login.

Authentication is actually performed outside of main Squid process. When Squid starts, it spawns a number of authentication subprocesses. These processes read user credentials on stdin, and reply with “OK” or “ERR” on stdout. This technique allows you to use a number of different authentication protocols (named “schemes” in this context). When multiple authentication schemes are offered by the server (Squid in this case), it is up to the User-Agent to choose one and authenticate using it. By RFC it should choose the safest one it can handle; in practice usually Microsoft Internet Explorer chooses the first one it’s been offered that it can handle, and Mozilla browsers are bug-compatible with the Microsoft system in this field.

In addition to the well known Basic authentication Squid also supports the NTLM, Negotiate and Digest authentication schemes which provide more secure authentication methods, in that where the password is not exchanged in plain text over the wire. Each scheme have their own set of helpers and auth_param settings. Notice that helpers for different authentication schemes use different protocols to talk with squid, so they can’t be mixed.

For information on how to set up NTLM authentication see NTLM config examples.

The Squid source code bundles with a few authentication backends (“helpers”) for authentication. These include:

• DB: Uses a SQL database.
• getpwam: Uses the old-fashioned Unix password file.
• LDAP: Uses the Lightweight Directory Access Protocol.
• MSNT: Uses a Windows NT authentication domain.
• MSNT-multi-domain: Allows login to one of multiple Windows NT domains.
• NCSA: Uses an NCSA-style username and password file.
• NIS (or YP): Uses the NIS database
• PAM: Uses the Unix Pluggable Authentication Modules scheme.
• POP3: Uses an email server to validate credentials. Useful for single-signon to proxy and email.
• RADIUS: Uses a RADIUS server for login validation.
• SASL: Uses SASL libraries.
• SMB: Uses a SMB server like Windows NT or Samba.
• SSPI: Windows native authenticator

Documentation for each of these helpers can be found at http://www.squid-cache.org/Doc/man/. Due to its simplicity Basic authentication has by far the most helpers, but the other schemes also have several helpers available.

In order to authenticate users, you need to compile and install one of the supplied authentication helpers, one of the others, or supply your own.

You tell Squid which authentication helper program to use with the auth_param directive in squid.conf. Specify the name of the program, plus any command line options if necessary. For example:

(full configuration details for the specific helper you choose can be found in the manual pages linked above).

�� How do I use authentication in access controls?

Make sure that your authentication program is installed and working correctly. You can test it by hand.

Add some proxy_auth ACL entries to your squid configuration. For example:

The REQUIRED term means that any already authenticated user will match the ACL named foo.

Note that allow will NOT trigger the 407 authentication denial to fetch new auth details if the user is not correctly logged in already. Some browsers will send anonymous auth details by default.

A slightly better way to do this and ensure the browser auth gets validated is:

Squid allows you to provide fine-grained controls by specifying individual user names. For example:

In this example, users named lisa, sarah, joe, and frank are allowed to use the proxy at all times. Other users are allowed only during daytime hours.

The ConfigExamples area contains some detailed examples:

1. ConfigExamples/Authenticate/Bypass
2. ConfigExamples/Authenticate/Groups
3. ConfigExamples/Authenticate/Kerberos
4. ConfigExamples/Authenticate/Ldap
5. ConfigExamples/Authenticate/LoggingOnly
6. ConfigExamples/Authenticate/MultipleSources
7. ConfigExamples/Authenticate/Mysql
8. ConfigExamples/Authenticate/Ncsa
9. ConfigExamples/Authenticate/Ntlm
10. ConfigExamples/Authenticate/NtlmCentOS5
11. ConfigExamples/Authenticate/NtlmWithGroups
12. ConfigExamples/Authenticate/Radius
13. ConfigExamples/Authenticate/WindowsActiveDirectory

�� How do I ask for authentication of an already authenticated user?

If a user is authenticated at the proxy you cannot “log out” and re-authenticate. The user usually has to close and re-open the browser windows to be able to re-login at the proxy. A simple configuration will probably look like this:

There is a trick which can force the user to authenticate with a different account in certain situations. This happens if you deny access with an authentication related ACL last in the http_access deny statement. Example configuration:

In this case if the user requests www.google.com then the first http_access line matches and triggers re-authentication unless the user is one of the listed users.

Remember: it is the last ACL on a http_access line that determines whether authentication is performed. If the ACL deals with authentication a new challenge is triggered. If you didn’t want that you would need to switch the order of ACLs so that you get http_access deny !google_users google or to use the loop prevention method outlned below.

But you might also run into a loop of constant authentication challenges if you are not careful.

�� How do I prevent Login Popups?

The login dialog box which pops up asking for username and password is a feature of your web browser. It only happens when the web browser has no working credentials it can hand to Squid when challenged for login.

Squid will only challenge for credentials when they are not sent and required:

this might cause a login popup. However modern browsers have a built-in password manager or access to the operating system credentials where they can locate a first attempt. This is commonly called single-sign-on. It is worth noting that despite popular advertising would indicate, single-sign-on does work with any HTTP authentication mechanism since it is a client browser feature not a HTTP or proxy feature.

If the browser is unable to find any initial details you WILL get the login popup. Regardless of what we do in Squid.

To prevent incorrect login details being re-challenged after sign-on has failed all you have to do is prevent the login ACL being the last on the authentication line.

For example, this normal configuration will cause a login re-challenge until working details are presented:

This all hack will present a plain access denied page without challenging for different credentials:

�� How do I prevent Authentication Loops?

Another more subtle version of the above login looping happens when the loop is triggered by a group check rather than a username check.

Assume that you use LDAP group lookups and want to deny access based on an LDAP group (e.g. only members of a certain LDAP group are allowed to reach certain web sites). In this case you may trigger re-authentication although you don’t intend to. This config is likely wrong for you:

The http_access deny line would force the user to re-authenticate time and again if he/she is not member of the PROXY_ALLOWED group. This is perhaps not what you want. You rather wanted to deny access to non-members.

You need to rewrite this http_access line so that an ACL matches that has nothing to do with authentication. This is the correct example:

This way the http_access line still matches. But it’s the all ACL which is now last in the line. Since all is a static ACL (that always matches) and has nothing to do with authentication you will find that the access is just denied.

�� Does Squid cache authentication lookups?

It depends on the authentication scheme; Squid does some caching when it can.

Note: Caching credentials has nothing to do with how often the user needs to re-authenticate himself. It is the browser who maintains the session, and re-authentication is a business between the user and his browser, not the browser and Squid. The browser authenticates on behalf of the user on every request sent to Squid. What the Squid parameters control is only how often Squid will ask the defined helper if the password is still valid.

Successful Basic authentication results are cached for one hour by default. That means (in the worst case) it is possible for someone to keep using your cache up to an hour after they have been removed from the authentication database. You can control the expiration time with the auth_param basic credentialsttl configuration option.

Successful NTLM and Negotiate authentication results are tied to the client TCP connection state and each new request is validated against the stored credentials token. Credentials are thus “cached” only for as long as that TCP connection persists, each new TCP connection requires an entirely different authentication.

�� Are passwords stored in clear text or encrypted?

In the basic scheme passwords is exchanged in plain text. In the other schemes only cryptographic hashes of the password is exchanged.

Squid stores cleartext passwords in its basic authentication memory cache.

Squid writes cleartext usernames and passwords when talking to the external basic authentication processes. Note, however, that this interprocess communication occurs over TCP connections bound to the loopback interface or private UNIX pipes. Thus, its not possible for processes on other computers or local users without root privileges to “snoop” on the authentication traffic.

Each authentication program must select its own scheme for persistent storage of passwords and usernames.

For the digest scheme Squid never sees the actual password, but the backend helper needs either plaintext passwords or Digest specific hashes of the same.

In the NTLM or Negotiate schemes Squid also never sees the actual password. Usually this is connected to a Windows realm or Kerberos realm and how these authentication services stores the password is outside of this document but usually it’s not in plain text.

In side-band authentication, using the external_acl_type directive. There is a password= value which is possibly transfered to Squid from the helper. This value is entirely optional and may in fact have no relation to a real password so we cannot be certain what risks are actually involved. When received it is generally treated by Squid as a cleartext Basic authentication password and it may be passed a such to peer proxies or services.

�� Can I use different authentication mechanisms together?

Yes, with limitations.

Commonly deployed user-agents support at least one and up to four different authentication protocols (also called schemes).

Those schemes are explained in detail elsewhere (see Features/NegotiateAuthentication and SquidFaq/TroubleShooting). You can enable more than one at any given moment, just configure the relevant auth_param sections for each different scheme you want to offer to the browsers.

RFC 2617, chapter 4.6, states: A user agent MUST choose to use the strongest auth-scheme it understands. Of course definition of strongest may vary

Due to a bug in common User-Agents (most notably some Microsoft Internet Explorer and Firefox versions) the order the auth-schemes are configured is relevant. Early versions of MSIE instead chooses the first auth-scheme (in the order they are offered) it understands.

In other words, you SHOULD use this order for the auth_params directives:

omitting those you do not plan to offer.

Once the admin decides to offer multiple auth-schemes to the clients, Squid can not force the clients to choose one over the other.

�� Can I use more than one user-database?

Generally speaking the answer is no, at least not from within Squid.

Unix’s PAM authentication method is quite flexible and can authenticate in an either/or/both fashion from multiple authentication sources.

You can configure two different authentication schemes with different user database. However since there is no control over which the browser chooses to use. This is an unreliable option, if it works for you great, if not there is nothing we can do to help.

The web server Basic authentication scheme provides another approach, where you can cook a proxy script which relays the requests to different authenticators and applies an ‘OR’ type of logic. For all other auth-schemes this cannot be done; this is not a limitation in squid, but it’s a feature of the authentication protocols themselves: allowing multiple user-databases would open the door for replay attacks to the protocols.

�� References

�� Authentication in interception and transparent modes

Simply said, it’s not possible to authenticate users using proxy authentication schemes when running in interception or transparent modes. See SquidFaq/InterceptionProxy for details on why.

�� Can I write my own authenticator?

Squid has a large range of versatile helpers to integrate with a very large number of popular authentication backends. Including custom-built corporate databases. Take a look through the bundled helpers manuals and online search engines. You will likely find someone has already done the hard work.

However, you may still find the need to write your own one for some system which has not been dreamed of yet. The protocol(s) Squid uses to communicate with its authentication helpers are very simple, and there are several examples in the wiki

�� Other Resources

Contents are © their respective authors,
licensed under the Creative Commons Attribution Sharealike 2.5 License
Last generated on 2023-02-20 14:03:04 +0000

Squid+LDAP. Часть 2

В данном разделе мы рассмотрим аутентификацию с помощью ориентированных на LDAP хелперов squid: squid_ldap_auth и digest_ldap_auth, представляющих, соответственно, Basic и Digest-аутентификации HTTP, а также коротко остановимся на других схемах аутентификации squid.

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

При Digest-аутентификации предоставленный пользователем пароль на клиенте соединяется с другимим данными, к этому значению применяется односторонняя хэш-функция MD5 и полученное значение вместе с именем пользователя передаётся на сервер, который на основании этих сведений пытается установить подлинность пользователя. Если злоумышленник перехватит захэшированную строку, получить из неё пароль в открытом виде не получится (в этом и смысл односторонней хэш-функции).

2.1 Basic-аутентификация: basic_ldap_auth (squid_ldap_auth)

Смысл работы хелпера basic_ldap_auth заключается в выполнении операции простого подсоединения (simple bind) к каталогу LDAP. По сути, операция простого подсоединения представляет собой прохождение аутентификации в каталоге от имени той записи каталога, которая описывает пользователя, с предоставлением пароля в открытом виде. Всё предельно просто: если подсоединение к каталогу прошло успешно, значит и аутентификация в squid считается успешно выполненной.

Чтобы выполнить простое подсоединение к каталогу, нужно знать DN записи, от имени которой будет выполняться подсоединение, и пароль. Пароль, как нам известно, предоставляется HTTP-клиентом в открытом виде, так что с этим вопросов нет. А вот DN пользовательской записи должен быть каким-то образом сопоставлен с предоставленным HTTP-клиентом именем пользователя. Хелпер basic_ldap_auth может решать эту задачу двумя разными способами:

Составление DN из значений аргументов комадной строки и переданного имени пользователя. Проще всего показать это на примере:

Пример 2.1.1. Составление DN. Аутентификация пользователей из ветки Managers

Примечание: Здесь и далее в примерах жирным шрифтом выделен текст, вводимый пользователем, а в угловых скобках указаны клавиши, на которые необходимо нажать в процессе или после ввода.

Примечание: Указываемый во всех примерах вызова хелперов из командной строки аргумент -d означает, что хелперы запускаются в режиме отладки, когда на стандартный вывод посылаются диагностические и служебные сообщения. При тестировании это очень удобно, но когда вызов хелпера прописывается в squid.conf , указывать его не следует.

Как видите, DN записи пользователя составляется из имени атрибута, переданного в качестве значения аргумента -u , имени пользователя и DN базовой записи, переданного в качестве значения аргумента -b . Затем происходит попытка аутентификации в каталоге с использованием полученного DN и переданного пароля.

Это самый простой способ использования хелпера basic_ldap_auth, при котором происходит всего одна операция с каталогом: простое подсоединение. Тем самым уменьшаются накладные расходы и время отклика хелпера, что немаловажно в нагруженных системах. Конечно же, такая простота возможна только при определённых условиях:

• Все записи пользователей, которым требуется прохождение аутентификации в squid, должны находиться в одной ветке каталога на одном уровне. Как видите, в нашем случае это не так, и пользователи, записи которых находятся в ветке People, не могут пройти аутентификацию. Хотя это может быть неплохим вариантом, если задача формулируется так: «Доступ в интернет получают не все подряд, а только руководители (пользователи из ветки Managers)».
• Значение атрибута в RDN записи должно соответствовать вводимому пользователем при аутентификации в squid имени. В нашем случае это условие выполняется (uid=vasily), но так бывает не всегда.

Более комплексный вариант определения DN записи можно сформулировать так: «Поиск в каталоге записей, удовлетворяющих заданным критериям. Затем DN первой из найденных записей используется для простого подсоединения.» Таким образом, взаимодействие с каталогом происходит как минимум в два этапа: анонимный поиск записей и попытка выполнить подсоединение. Если же анонимный поиск в каталоге запрещён (как, например, в Microsoft AD), то этапов уже три: подсоединение к каталогу от имени записи с правами поиска (аргументы -D и -w ( -W )), поиск записи по указанным критериям и попытка повторного подсоединения от имени найденной записи.

Ключевым моментом для запуска хелпера в этом режиме является наличие аргумента -f , значением которого является поисковый фильтр LDAP. В этом случае значение аргумента -b рассматривается как база поиска, а диапазон поиска, при необходимости, можно задать аргументом -s (по умолчанию — sub).

Итак, какие же реальные преимущества мы можем получить взамен дополнительной нагрузки на каталог LDAP? Попробуем разобрать это на примерах.

Пример 2.1.2. Классический. Аутентификация пользователей из всего каталога

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

На первом этапе осуществляется поиск записей, соответствующих указанным критериям поиска. В данном случае базой поиска ( -b ) будет базовая запись всего каталога dc=mycompany,dc=ru, диапазон поиска не указан, поэтому берётся значение по умолчанию sub. Таким образом, при поиске будет осуществляться обход всего дерева каталога, в том числе и обоих интересующих нас веток People и Managers. Чтобы отобрать только записи пользователей, мы указываем фильтр -f ‘(uid=%s)’ . Шаблон %s в этой конструкции заменяется на вводимое значение имени пользователя. Как видно в примере, в первом случае в результате был сформирован фильтр (uid=vasily) , во втором —  (uid=anton) , в третьем —  (uid=petr) , соответственно были найдены записи пользователей из обоих веток uid=vasily,ou=Managers,dc=mycompany,dc=ru и uid=anton,ou=People,dc=mycompany,dc=ru, а в третьем случае поиск не дал результатов, хотя и прошёл успешно, о чём свидетельствует забавный вывод ERR Success .

Если запись была найдена, осуществляется попытка простого подсоединения к каталогу от имени этой записи с предоставленным паролем. Факт удачного подсоединения к каталогу означает, что basic-аутентификация прошла успешно ( OK ).

Таким образом, поиск в каталоге даёт нам возможность находить записи любых пользователей независимо от того, в какой ветке (подветке) они хранятся.

Пример 2.1.3. Дополнительный критерий. Аутентификация только членов определённой группы

Часто возникает задача предоставить доступ в Интернет не всем пользователям подряд, а лишь определённому подмножеству. Выделить такое подмножество можно, задав определённое значение какого-либо атрибута, к примеру, ou: Inet Users в записях тех пользователей, которым разрешён доступ в Интернет. В этом случае можно было бы использовать фильтр -f ‘(&(uid=%s)(ou=Inet Users))’ . В нашем тестовом каталоге таких атрибутов нет, но мы можем смоделировать ситуацию, когда используя определённые группы и наложение обратного членства в них ( memberof ), мы получим операционные (скрытые) атрибуты с указанием на членство в группе. Эти атрибуты мы можем использовать при построении фильтра.

Задача: провести аутентификацию только тех пользователей, которые входят в группу cn=InetUsers,ou=Groups,dc=mycompany,dc=ru, членам которой разрешён доступ в Интернет.

Для начала нам необходимо создать группу, причём такую, чтобы можно было использовать её для наложения memberof (подробнее о группах речь пойдёт далее). Для определения группы будем использовать объектный класс groupOfUniqueNames :

Членами нашей группы (значения атрибута uniqueMember ) будут пользователи из разных веток, таким образом мы обозначаем, что расположение записей пользователей в каталоге может быть произвольным. Добавим нашу группу с помощью ldapadd и настроим для нашего DIT наложение memberof на использование объектного класса groupOfUniqueNames и атрибута uniqueMember . Проверим, что получилось:

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

В данном случае мы ищем по всему каталогу (база поиска -b ‘dc=mycompany,dc=ru’ , диапазон по умолчанию — sub), вторым критерием в фильтре является соответствие значения атрибута memberOf DN заданной группы. Пользователи vasily и vitaly, являющиеся членами нашей группы, успешно прошли аутентификацию, а пользователь anton — нет. Это чем-то схоже с отбором по группам, но есть существенное отличие: в фильтре можно задавать только конкретные значения групп или других атрибутов (одно или несколько), получается пресловутое «одним — всё, а другим — ничего». Если же нам нужна ситуация, когда «одним — одно, вторым — другое, третьим — третье, а остальным — ничего», то без использования хелпера ext_ldap_group_acl не обойтись.

Пример 2.1.4. Другой атрибут. Аутентификация только пользователей из определённой ветки, другой вариант

Бывает так, что значение атрибута, образующего RDN записи пользователя, не соответствует имени учётной записи пользователя. Первое, что приходит в голову, — каталог Microsoft AD, где RDN образовано атрибутом cn (например, cn=Vitaly Fridzon), а в качестве логина чаще всего используется значение атрибута sAMAccountName . Применительно к нашему экспериментальному каталогу можно поставить задачу так: предоставлять доступ в Интернет только руководителям, аутентификацию проходить по фамилии. Решение:

Ограничив область ( -b ‘ou=Managers,dc=mycompany,dc=ru’ ) и диапазон ( -s one ) поиска, мы, во-первых, получили точное соответствие условиям нашей задачи, а во-вторых, снизили нагрузку на сервер. Фильтр -f ‘(sn=%s)’ позволяет нам отобрать записи по значению атрибута sn , не фигурирующего в RDN. В нашем случае в результате преобразования шаблона мы получили фильтр (sn=karasev) , по которому была найдена запись uid=vasily,ou=Managers,dc=mycompany,dc=ru и от имени этой записи было выполнено успешное подсоединение к каталогу ( OK ).

Пример 2.1.5. Несколько шаблонов. Значения разных атрибутов в качестве имени пользователя

При построении фильтра в хелпере basic_ldap_auth можно использовать шаблон %s несколько раз (до 16-ти, согласно документации). Это может пригодиться, если записи у Вас в каталоге устроены по разному и логин хранится в разных атрибутах. В нашем каталоге это не так, но мы можем поставить иную задачу: аутентифицировать пользователей по их логину, либо по фамилии. Решение:

Поиск происходит по всему каталогу (база поиска -b ‘dc=mycompany,dc=ru’ , диапазон по умолчанию — sub). Фильтр -f ‘(|(uid=%s)(sn=%s))’ в первом случае преобразуется в (|(uid=anton)(sn=anton)) , во втором — в (|(uid=ponkrashov)(sn=ponkrashov)) . В результате обоих поисков найдена одна и та же запись uid=anton,ou=People,dc=mycompany,dc=ru, от имени которой и происходит подсоединение к каталогу.

Пример 2.1.6. Дурашливый. Аутентификация только пользователей, начинающихся с определённой буквы

Ещё один пример поиска с дополнительным критерием. На этот раз в результат поиска попадают только пользователи, значение атрибута uid которых начинается с буквы v.

2.1.1. Настройка вызова хелпера basic_ldap_auth в файле squid.conf

1. определить параметры вызова и работы самого хелпера,
2. определить ACL аутентификации,
3. наконец, определить правило доступа, использующее этот ACL.

Нагляднее рассмотреть это на примере. Для начала покажем возможные параметры вызова хелпера и разные варианты определения ACL, затем рассмотрим их подробнее:

В строках 1-13 определяются настройки Basic-аутентификации. Все директивы настройки Basic-аутентификации начинаются с ключевых слов auth_param basic . Строка 3 интересует нас больше всего, поскольку в ней описывается непосредственно вызов хелпера, на что указывает ключевое слово program . Для этой конфигурации мы используем вызов хелпера с «классическим» вариантом поиска записей в каталоге (смотрите пример 2.1.2 выше), Вы же должны указать параметры, соответствующие Вашей задаче. Аргумент -d мы не указываем, поскольку он нужен для вывода отладочной информации и в рабочей системе будет только мешать. Для примера мы указали аргумент -H , значением которого является URL размещения каталога; если, как в нашем случае, каталог обслуживается на том же сервере и на стандартном порту, данный аргумент можно не указывать. Возможно, Вас заинтересуют и другие аргументы подключения к LDAP-серверу ( -P , -O , -Z ), их назначение смотрите в man-странице basic_ldap_auth. Ещё раз необходимо обратить внимание на то, что значения аргументов хелпера обрамляются двойными кавычками (с одинарными хелпер просто не будет вызываться).

Все остальные директивы auth_param basic являются опциональными. В строке 5 указывается область действия аутентификации (ключевое слово realm ). Для Basic-аутентификации принципиального значения этот параметр не несёт, он выводится как подсказка в диалоге запроса аутентификации. Значение по умолчанию — »Squid proxy-caching web server». В строке 7 указывается, сколько одновременных процессов хелпера будет порождать squid (ключевое слово children ). Тут, как говорится, чем больше, тем лучше, главное, чтобы памяти хватало. Значение по умолчанию — 5. В строке 9 указывается «время жизни» результатов аутентификации, то есть как часто повторно вызывается хелпер для проверки аутентификации пользователя с тем же именем. Значения по умолчанию тут нет, многое зависит от того, часто ли у Вас меняются пароли.

Существует ещё несколько директив Basic-аутентификации. В нашем случае они не несут смысловой нагрузки, поэтому мы оставили их закомментированными. В строке 11 указана директива с ключевым словом utf8 . Имеет смысл включить её, если в имени пользователя или пароле имеются символы, не входящие в набор iso-latin-1, например, кириллические (в нашем случае это не так). Значение по умолчанию — »off». Наконец, в строке 13 указана директива с ключевым словом casesensitive , то есть чувствительность имени пользователя к регистру символов. В LDAP практически все (за редким исключением) строки к регистру нечувствительны, соответственно, включать этот параметр нет смысла — он не будет работать в любом случае. Значение по умолчанию — »off».

Далее, в строках 15-21, определяются списки контроля доступа (ACL) аутентификации. Как и любые директивы списков контроля доступа, они начинаются с ключевого слова acl , затем следует имя списка и его тип, после чего указываются дополнительные параметры для конкретного типа ACL. Мы рассмотрим 3 варианта ACL аутентификации. Первый из них (строка 17) сработает при успешном прохождении аутентификации любым пользователем. Мы назвали его acl_all_authed_users. Этот вариант используется чаще всего, особенно когда дальнейшее разделение пользователей по группам происходит с помощью каких-либо хелперов внешних ACL.

Другие два варианта (закомментированы в строках 19 и 21) позволяют произвести примитивное разбиение пользователей по группам уже на этапе аутентификации без использования дополнительных ACL. В первом из них (мы назвали его acl_some_authed_users) после ключевого слова proxy_auth , указывающего на тип ACL, явно перечисляются те пользователи, при успешной аутентификации которых этот ACL сработает. Такой вариант разбиения по группам приемлем лишь в системах с небольшим количеством пользователей, которые редко меняются. В последнем из рассматриваемых вариантов (acl_regex_authed_users) после ключевого слова proxy_auth_regex , указывающего на тип ACL, и опции -i приводится регулярное выражение. Этот ACL сработает, если имя пользователя, успешно прошедшего аутентификацию, соответствует указанному в нём регулярному выражению (в нашем случае имя пользователя начинается с буквы a). Как видите, такой подход может быть приемлем только в системах со специфичными условиями. Выбирайте тот вариант, который Вам больше подходит.

Опция -i в последнем ACL приводится для примера и означает, что имя пользователя будет рассматриваться как строка, нечувствительная к регистру символов. Эту опцию можно использовать в любом ACL (не только аутентификации).

Наконец, в строках 23-31 с помощью директив http_access определяются правила доступа на основании ранее определённых ACL. Тут всё просто: срабатывает указанный по имени ACL (основной в строке 25 и два других варианта в закомментированных строках 27 и 29) — срабатывает и правило, и доступ в Интернет разрешён (ключевое слово allow ), нет — срабатывает последнее правило в строке 31, запрещающее доступ в Интернет (ключевое слово deny и ACL по умолчанию all). Другими словами, аутентификация пройдена — есть доступ, нет — нет.

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

2.2. Digest-аутентификация: digest_ldap_auth

Работа хелпера digest_ldap_auth несколько отличается от работы других хелперов squid тем, что именно он возвращает серверу squid. Это связано со спецификой работы Digest-аутентификации: если после обработки входных параметров хелпер принял отрицательное решение, то он возвращает ERR, а если положительное, то так называемое значение H(A1) (в других источниках — HA1). На основании этого значения и других данных сервер squid вычисляет так называемое значение response, и, если оно совпало с аналогичным значением, вычисленным и переданным клиентом, аутентификация считается успешно пройденной.

Что же представляет из себя значение H(A1)? Это MD5-хэш от строки, собранной из имени пользователя, наименования области действия аутентификации (realm) и пароля пользователя, объединённых через двоеточие, то есть:

Хелпер digest_ldap_auth получает на вход строку, состоящую из взятого в кавычки имени пользователя и взятого в кавычки наименования области действия аутентификации, объединённых через двоеточие, то есть:

Итак, два из трёх значений уже есть. Осталось только обратиться к каталогу LDAP, определить запись-источник данных, получить оттуда недостающие данные и выдать соответствующее этому пользователю и области значение H(A1). Хелпер может сделать это двумя разными способами:

1. При наличии в каталоге пароля в открытом виде (как в нашем случае) сформировать требуемую строку и получить её MD5-сумму не составляет труда.
2. Готовое значение H(A1) заранее помещается в запись каталога, а хелперу указывается, в каком атрибуте его можно получить.

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

Пример 2.2.1. Составление параметров определения записи + пароли в открытом виде. Аутентификация пользователей из ветки Managers

Как и basic_ldap_auth, при вызове с аргументами -b и -u хелпер digest_ldap_auth работает в режиме составления DN записи из значений этих аргументов и переданного имени пользователя. В аргументе -A указывается атрибут записи пользователя, содержащий пароль для Digest-аутентификации. В данном вызове мы не указали аргумент -e , сообщающий хелперу о том, что в атрибуте (заданном в аргументе -A ) содержится уже сформированное значение H(A1), поэтому хелпер считает, что в этом атрибуте содержится пароль в открытом виде. Обратите внимание, что для Digest-аутентификации squid у пользователя может быть отдельный пароль, хранящийся в совершенно другом атрибуте, и указывать, конечно же, требуется нужный атрибут. Просто в нашем случае так совпало, что хелпер получает нужное значение из основного парольного атрибута userPassword .

С аргументами разобрались, теперь перейдём к передаваемым входным параметрам. Как мы уже знаем, это строка, состоящая из взятого в кавычки имени пользователя и взятого в кавычки наименования области действия аутентификации, объединённых через двоеточие. Если эта строка сформирована неправильно, хелпер сразу выдаёт ошибку, как в первом случае. Во втором случае строка сформирована правильно, хелпер извлекает из неё имя пользователя и формирует утверждение uid=anton (название атрибута uid передано в аргументе -u ). Тут поведение digest_ldap_auth отличается от basic_ldap_auth, ведь для выполнения подсоединения достаточно иметь DN записи, а для извлечения значения из записи требуется получить саму запись. Поэтому полученное утверждение uid=anton используется не как RND, а как фильтр для выполнения поиска с базой, переданной в аргументе -b . Во втором случае поиск с фильтром uid=anton в ветке ou=Managers,dc=mycompany,dc=ru результатов не даёт и возвращается ошибка ERR No such user . В третьем случае поиск с фильтром uid=vasily в той же ветке возвращает соответствующую запись, из неё извлекается значение атрибута userPassword (передан в аргументе -A ), формируется значение H(A1) и выдаётся на стандартный выход. Получив это значение, squid сам принимает решение, прошёл пользователь аутентификацию, или нет. Следует отметить, что если при выполнении поиска запись будет найдена, но в ней не окажется нужного атрибута, хелпер также выдаст ошибку ERR No such user .

Пример 2.2.2. Поиск требуемой записи + готовое значение H(A1). Аутентификация пользователей всего каталога

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

1. Сформировать значение H(A1).
2. Определить атрибут записи, в котором хелпер будет искать значение H(A1).
3. Модифицировать запись пользователя, поместив сформированное значение в выбранный атрибут.

Для нашего примера возьмём пользователя anton, область аутентификации Squid Digest Auth и пароль antonDigestPassword. Сформируем H(A1):

Не будем оригинальничать и в качестве атрибута для хранения H(A1) возьмём, как и в официальном руководстве, атрибут l ( location ). Разумеется, можно взять и любой другой незанятый атрибут объектного класса inetOrgPerson (в нашем случае). Сформируем файл anton_digest.ldif такого содержания:

Как видно, в запись пользователя anton добавляется выбранный нами атрибут l со значением, состоящим из названия области аутентификации и сформированного H(A1), разделённых двоеточием (разделитель может быть и иным, тогда его нужно явно указывать в аргументе -l хелпера digest_ldap_auth ). Название области аутентификации приводится в этом значении на тот случай, если пользователь проходит Digest-аутентификацию в нескольких разных системах с разными паролями.

Применим наши изменения:

Посмотрим, что у нас получилось:

Осталось протестировать собственно Digest-аутентификацию (напомним, поиск записей пользователей будет вестись по всему каталогу):

Аргументы -b , -s и -F задают критерии поиска записей в каталоге LDAP: базу поиска, диапазон поиска и фильтр, соответственно. Всё это нам уже знакомо по хелперу basic_ldap_auth , также как и наличие шаблона %s в поисковом фильтре, который заменяется на имя пользователя, получаемое из входной строки. Самые интересные для нас аргументы: -e  — говорит о том, что в каталоге в записи пользователя хранится уже сформированное значение H(A1), и -A  — указывает атрибут записи, из которого это значение можно извлечь (в данном случае атрибут l ).

На вход хелпер принимает уже знакомую нам строку, состоящую из взятого в кавычки имени пользователя и взятого в кавычки наименования области действия аутентификации, объединённых через двоеточие. В первом случае из входной строки сформирован фильтр uid=vasily , в результате поиска с базой dc=mycompany,dc=ru и диапазоном sub была найдена запись uid=vasily,ou=Managers,dc=mycompany,dc=ru , но в ней не оказалось искомого атрибута l , поэтому хелпер вернул ошибку. Во втором случае был указан пользователь anton , в записи которого присутствует искомый атрибут l , но имя области аутентификации указано неверно (не совпадает с именем в атрибуте l ). В результате получить значение H(A1) для запрашиваемой области аутентификации не удалось и хелпер вновь вернул ошибку. Наконец, в третьем случае переданные параметры позволили найти запись uid=anton,ou=People,dc=mycompany,dc=ru и извлечь из неё требуемое значение H(A1), которое хелпер вернул на стандартный вывод.

2.2.1. Настройка вызова хелпера digest_ldap_auth в файле squid.conf

1. определить параметры вызова и работы самого хелпера,
2. определить ACL аутентификации,
3. определить правило доступа, использующее этот ACL.

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

В строках 1-19 определяются настройки Digest-аутентификации. Все директивы настройки Digest-аутентификации начинаются с ключевых слов auth_param digest . В строках 3-5 описывается вызов хелпера, на что указывает ключевое слово program . В данном случае мы воспользовались вариантом вызова хелпера из примера 2.2.2, несколько расширив фильтр поискового запроса LDAP для более точного отбора интересующих нас записей каталога. Также мы указали аргумент -H чтобы показать, с какого именного LDAP-сервера мы хотим получать данные, опустили аргумент -d (в рабочей системе вывод отладочной информации излишен) и добавили аргумент -P (установка постоянного соединения с LDAP-сервером, чтобы не тратить время на повторные подключения).

В строке 7 указывается область действия аутентификации (ключевое слово realm ). В отличие от Basic-аутентификации, данный параметр для Digest-аутентификации крайне важен, поскольку на его основе строятся различные значения, которыми обмениваются клиент и сервер в процессе аутентификации, в том числе значение H(A1). Здесь обязательно следует указывать именно то имя области аутентификации, которое мы использовали при формировании значения H(A1) для записей пользователей в LDAP-каталоге.

Все остальные директивы auth_param digest являются опциональными. Часть из них мы уже обсуждали при настройке Basic-аутентификации, описание других можно посмотреть в комментариях файла squid.conf.default . Информацию по отметке nonce можно найти в RFC 7616.

Списки контроля доступа (строки 21-23) и настройка разграничения доступа на их основе (строки 25-29) подробно обсуждались в примере по Basic-аутентификации. При успешном прохождении аутентификации пользователь получает доступ, в противном случае — нет.

2.3. Другие схемы аутентификации squid

Кроме двух рассмотренных схем аутентификации, squid поддерживает ещё схемы NTLM и Negotiate. Обе они были разработаны для интеграции squid в концепцию Microsoft SSO (Single Sign On, технология единого входа). Поскольку прямого отношения к LDAP они не имеют, мы рассмотрим их очень кратко, чтобы в дальнейших примерах иметь некоторое представление об их работе.

NTLM-аутентификация для проверки подлинности пользователя использует обмен пакетами NTLMSSP, характерными для доменов Windows NT (samba3). Официальное HOWTO по настройке NTLM-аутентификации. Для нас важно, что после прохождения NTLM-аутентификации в переменную squid %LOGIN помещается конструкция ИМЯ_ДОМЕНА_WINNT+разделитель+имя_пользователя, например, MYCOMPANY\alex.

Аутентификация пользователей прокси-сервера Squid

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

В нашей предыдущей публикации были разобраны базовые возможности конфигурации кэширующего прокси-сервера Squid посредством изменения основного файла настроек. В этой статье будут рассмотрены более продвинутые возможности настройки Squid, позволяющие осуществлять аутентификацию пользователей.

Несмотря на большие возможности базовой конфигурации, некоторые функции, необходимые для комфортной работы прокси-сервера, возложены на дополнительные программы, называемые “хелперами”. Одна из самых важных задач, для решения которой создано множество хелперов, это аутентификация пользователей. Сам прокси-сервер Squid не осуществляет аутентификацию, он лишь способен декодировать HTTP-заголовок Authorization и передать расшифрованную информацию хелперу. Хелпер проверяет корректность переданных данных и в зависимости от того, верна ли связка логин-пароль отвечает прокси-серверу. После этого Squid проверяет права доступа и предоставляет пользователю доступ, или же возвращает 407 ошибку HTTP, если аутентификация не пройдена.

Хелперы, способные производить аутентификацию клиентов сети некоторыми основными способами входят в состав пакета Squid. Любой хелпер работает согласно своей схеме аутентификации и возвращает прокси-серверу положительный или отрицательный результат. Одновременно могут быть сконфигурированы несколько схем аутентификации, прокси-сервер будет пытаться использовать разные схемы аутентификации в зависимости от порядка их указания в squid.conf.

Очень важно помнить, что аутентификация невозможна в прозрачном режиме работы прокси-сервера (transparent proxy). Это ограничение вызвано исключительно особенностями работы протокола TCP/IP, а не недостатками функционала Squid.

Включение и настройка сторонних модулей аутентификации выполняется с помощью директивы auth_param главного конфигурационного файла:

auth_param scheme parameter [setting]

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

После настройки аутентификации и выбранного хелпера обязательно создать acl (access control list — список контроля доступа), который задействует настроенный модуль аутентификации и позволит получить доступ к сети авторизованным пользователям.

Изначально строка задания acl имеет следующий формат:

acl acl_name acl_type argument

Для создания списка контроля доступа, который включает в себя пользователей, прошедших аутентификацию, параметр acl_type должен иметь значение proxy_auth. Не стоит забывать, что данный acl должен иметь разрешение на доступ, которое выдаётся с помощью директивы http_access .

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

Basic метод аутентификации — это простейший метод проверки подлинности, который существовал ещё в протоколе HTTP/1.0. Он основан на предоставлении прокси-серверу учетных данных веб-браузером клиента. Логин и пароль объединяются через двоеточие, кодируются в base64 и передаются в поле Authorization HTTP-запроса. Следует обратить внимание, что кодирование учетных данных в base64 не является защитой и фактически происходит открытая передача пароля. Единственное преимущество basic схемы это то, что её поддерживает любой браузер или другой клиент работы с сетью.

Атентификация с использованием NCSA

Хранение паролей осуществляется с помощью обычного текстового файла, который содержит учетные данные, закодированные в base64. По умолчанию в Squid basic-аутентификация реализуется с помощью хелпера, расположенного в /usr/lib/squid3/ncsa_auth. Он проверяет соответствие переданной комбинации «логин:пароль» с хранящимися в файле данными и возвращает прокси-серверу “OK” или “ERR” в качестве результата.

Стоит обратить внимание, что даже в случае удачной аутентификации пользователь может не получить доступ в сеть — на авторизованных пользователей могут распространяться любые правила контроля доступа, записанные в acl главного конфигурационного файла Squid. Поэтому в первую очередь добавим в конфиг прокси-сервера настройки для работы хелпера basic-аутентификации:

Файл паролей для реализации Basic аутентификации можно создать с помощью утилиты htpasswd, которая входит в состав пакета apache2-utils для Debian/Ubuntu. Синтаксис команды для htpasswd следующий:

htpasswd [-c] /создаваемый/файл/паролей имя_пользователя

Параметр -с используется для создания нового файла, изменение существующего файла производится без этого параметра.

Ниже приведен пример создания нового файла учетных записей squidusers и добавления пользователей user1 и user2 с паролями 12345:

Для созданного файла желательно установить права на чтение только пользователю и группе, от имени которой работает Squid:

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

squid3 -k reconfigure или /etc/init.d/squid3 reload

Аутентификация с использованием базы данных MySQL

Помимо хранения учетных данных в файле можно воспользоваться basic-аутентификацией через базу данных. В этом случае связки «логин:пароль» будут храниться в базе данных MySQL.

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

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

Настройка на стороне MySQL завершена, теперь необходимо подключить DB-аутентификацию в файле настроек squid.conf аналогичным обычной basic-аутентификации способом:

Отдельное внимание стоит уделить основным параметрам хелпера:

• —user — имя пользователя БД;
• —password — пароль доступа к БД;
• —table — таблица в БД, по умолчанию «passwd»;
• —usercol — столбец с именами пользователей, по умолчанию «user»;
• —passwdcol — столбец с паролями, по умолчанию»password»;
• —plaintext — означает, что пароли в базе хранятся в открытом виде;
• —md5 — означает, что пароли зашифрованы в md5 без добавления “соли”;
• —salt — “соль”, используемая для шифрования пароля;
• —persist — оставляет соединение с БД открытым в промежутке между запросами.

По завершении настройки необходимо обновить конфигурацию прокси-сервера командой

Помимо хелперов NCSA и MySQL, в состав Squid также входит множество других хелперов для работы с такими источниками данных, как LDAP, RADIUS, PAM и другие.

Digest-аутентификация

Данный метод является более предпочтительным, чем basic-аутентификация благодаря использованию шифрования пароля перед отправкой через сеть. Общая схема работы примерно та же, что и в basic методе, за исключением того, что при обмене между клиентом и сервером учетные данные шифруются с использованием MD5-шифрования. В ответы клиента и сервера добавляются случайные значения, после этого пароль передаётся в виде хэша. Шифровку и дешифровку пароля может производить утилита htdigest, которая устанавливается вместе с пакетом apache2-utils. Хелпер, позволяющий реализовать Digest-аутентификацию с помощью файла с паролями, можно найти по адресу /usr/lib/squid3/digest_pw_auth.

Также как и для Basic-аутентификации, для Digest-аутенфикации существуют и другие хелперы, позволяющие использовать разные источники данных о пользователях.

Помимо Basic- и Digest-аутентификации, Squid также поддерживает NTLM- и Negotiate-аутентификацию. Данные схемы применяются достаточно редко, как правило, в рамках корпоративной инфраструктуры и их настройка заслуживает отдельной статьи.

Общие настройки аутентификации пользователей

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

children

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

realm

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

credentialsttl

Параметр, отвечающий за срок хранения в кэше связки «username:password». Когда заданный промежуток времени истечет, прокси-сервер вновь запросит у пользователя аутентификацию.

casesensitive

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

blankpassword

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

Дополнительные директивы

Кроме директивы auth_param есть так же несколько других директив, влияющих на аутентификацию:

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

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

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

Заключение

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

Введение любого из механизмов аутентификации связано с определенным уровнем дискомфорта для пользователей сети и возрастающей сложностью её обслуживания. Не стоит забывать, что аутентификация в режиме “прозрачного” Squid невозможна — каждый компьютер придется настраивать для работы через прокси-сервер. С точки зрения информационной безопасности, куда большее внимание стоит обратить на права пользователей и на принципиальную доступность некоторых файлов в сети. Поэтому перед тем, как реализовывать любой из механизмов аутентификации пользователей, стоит как следует продумать схему работы сети и ответить на вопрос “Можно ли достичь того же уровня безопасности без использования аутентификации всех клиентов?”

Аутентификация и авторизация squid (basic, Digest, NTLM, negotiate)

Приветствую всех, гостей и постоянных читателей блога. Сегодня попробую изложить информацию о методах аутентификации в squid, а так же интегрировать suid в доменную инфраструктуру Active Directory на Windows Server 2008 R2. То есть заставить squid разрешать доступ к интернету на основе доменных учетных записей. Для понимания происходящего, советую ознакомиться с предыдущими статьями о настройке сети в Linux и вводной статье о squid. Итак, приступим.

Введение

Из прошлой статьи о squid мы знаем, что в прозрачном режиме squid не способен аутентифицировать пользователей. Поэтому придется настроить пользовательские браузеры. Кроме того, мы знаем, что хороший админ — это ленивый админ и ходить пешком по рабочим станциям и настраивать вручную браузеры пользователей он не станет. Поэтому расскажу как через GPO мы настроим IE (для пользователей бабушек с особо клиническим случаем и для сайтов, использующих ActiveX. ), Firefox и Google Chrome. Все эти 3 браузера умеют настраиваться через GPO.

Squid в части авторизации и аутентификации подобен Web-серверу Apache и поддерживает те же способы аутентификации, что и Apache. На текущий момент существуют четыре основных типа проверки подлинности в HTTP протоколе:

• Basic — самая первая схема, часто используемая по текущий момент
• NTLM — это первая попытка Microsoft к SSO (single-sign-on) единого входа для ресурсов локальной сети
• Digest — она же дайджет аутентификация. Чуть защищенней basic
• Negotiate (aka SPNEGO) — она же Kerberos SPN generation — вторая попытка реализации Microsoft SSO

В статье я рассмотрю пример реализации basic аутентификации и Kerberos и кратко опишу NTLM и Digest.

Настройка адреса прокси через GPO в Windows Server 2008 R2

Настройка Internet Explorer через GPO

Желательно на всех машинах локальной сети обновить Internet Explorer до 7 версии, ибо с IE 6 доменная проверка подлинности не будет работать. Об этом Mictosoft официально заявляет . Настройка параметров прокси сервера задается в объекте групповой политики в разделе Конфигурация пользователя — Политики — Конфигурация Windows — Настройка Internet Explorer — Подключение — Параметры прокси-сервера: Т.к. данная настройка расположена в конфигурации пользователя, то и применяться будет к пользователям, расположенным в текущем подразделении OU, к которому будет применен Объект групповой политики.

Настройка Mozilla Firefox через GPO

1. Качаем MSI пакет FrontMotion Firefox Community Edition с http://www.frontmotion.com/FMFirefoxCE/download_fmfirefoxce.htm. (Обязательно Community Edition, ибо кроме CE-версии на данном сайте предлагается обычная сборка msi пакета, которая не принимает настройки из реестра GPO). Оттуда же качаем файлы административных шаблонов mozilla.admx и mozilla.adml, которые собственно и задают настройки групповых политик. Если у Вас сервер AD 2003 версии, то нужно скачивать firefox.adm и mozilla.adm.

2. Распространяем скачанный MSI пакет через объект GPO (как это сделать я описывал в статье установка программ через AD GPO).

3. Кладем скачанные файлы административных шаблонов. :

• Если используется централизованное хранилище , то mozilla.admx кладется в каталог %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\, а mozilla.adml — в %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\en-US\.
• Если используется локальное хранилище административных шаблонов, то mozilla.admx кладется в каталог %systemroot%\PolicyDefinitions\, а mozilla.adml — в %systemroot%\PolicyDefinitions\en-US\. После этого появиться новый раздел в настройках GPO.

4. Задаем настройки браузера в созданном объекте групповой политики. Настройки прокси-сервера задаются в разделе Конфигурация компьютера — Политики — Административные шаблоны — Mozilla Advanced Options — Locked Settings — network:

Т.к. данная настройка расположена в конфигурации компьютера, то и применяться будет к компьютеру всем пользователям, вошедшим в компьютер, расположенный в текущем подразделении OU, к которому будет применен Объект групповой политики. Кроме настроек прокси, браузер поддерживает еще туеву хучу настроек, о которых можно почитать тут http://kb.mozillazine.org/About:config_entries.

Настройка Google Chrome через GPO

1. Качаем MSI пакет Chrome с https://www.google.com/intl/en/chrome/business/browser/ или http://www.google.com/chrome/intl/ru/business/index.html. Качаем файлы административных шаблонов chrome.admx и chrome.adml, которые собственно и задают настройки — отсюда http://dl.google.com/dl/edgedl/chrome/policy/policy_templates.zip.

2. Распространяем скачанный MSI пакет через объект GPO (как это сделать я описывал в статье установка программ через AD GPO).

3. В скачанном архиве policy_templates.zip имеются каталоги policy_templates\windows\admx, из данного каталога кладем файлы административных шаблонов.

• Если используется централизованное хранилище административных шаблонов, то chrome.admx кладется в каталог %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\, а chrome.adml — в %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\ru-RU\.
• Если используется локальное хранилище административных шаблонов, то \ru\chrome.admx кладется в каталог %systemroot%\PolicyDefinitions\, а \ru\chrome.adml — в %systemroot%\PolicyDefinitions\en-US\. После этого появиться новый раздел в настройках GPO.

4. Задаем настройки браузера в созданном объекте групповой политики. Настройки прокси сервера задаются в разделе Конфигурация пользователя — Политики — Административные шаблоны — Google — Google Chrome — Прокси-сервер:

Т.к. данная настройка расположена в конфигурации пользователя, то и применяться будет к пользователям, расположенным в текущем подразделении OU, к которому будет применен Объект групповой политики. Кроме настроек прокси, браузер Crome поддерживает еще много настроек, о которых можно почитать в скачанном архиве в файле policy_templates\common\html\ru\chrome_policy_list.html. Кроме того, можно ознакомиться с Кратким руководством от гугла http://support.google.com/a/bin/answer.py?hl=ru&answer=187202.

Методы аутентификации SQUID

Начну с рассмотрения общих принципов организации аутентификации в squid. Если быть точным, то сам squid не выполняет никаких функций аутентификации. Работа squid по аутентификации заключается в декодировании HTTP заголовка Authorization и передаче декодированной информации — так называемому хелперу. Если предоставленная информация верна, то доступ пользователю предоставляется, если же не верна или отсутствует, то squid возвращает клиенту HTTP код 407. Более подробно этот процесс будет рассмотрен далее. Т.о. всю основную работу по проверке подлинности пользователей выполняют сторонние модули (они же — хелперы, они же helpers). Расположение этих модулей зависит от дистрибутива и версии SQUID, например в Debian+squid3 они расположены в каталоге /usr/lib/squid3, в Red Hat скорее всего их расположение будет в /usr/lib/squid. Просмотреть, какие методы проверки подлинности поддерживает Ваш сквид, размещение хелперов и многие другие параметры, можно командой squid3 -v, вывод которой содержит опции, с которыми squid был сконфигурирован, например:

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

Взаимодействие и описание настроек сторонних модулей аутентификации производится с помощью параметра auth_param. Клиент будет поочередно пытаться использовать схемы аутентификации в том порядке, в котором они заданы в squid.conf. При этом (ходят слухи, но я с этим не столкнулся), у IE есть баг, который заставляет использовать сначала basic аутентификацию, даже если до basic заданы другие более безопасные схемы.

Новая настроенная схема аутентификации вступит в силу только после перезапуска squid, при этом, внесение изменений в уже существующие настроенные схемы может производится без перезапуска демона (достаточно дать команду squid3 -k reconfigure или /etc/init.d/squid3 reload). Настроенный внешний модуль проверки подлинности еще не означает, что эта проверка будет работать и пускать пользователя в интернет. Для контроля доступа в интернет, необходимо создать acl, который будет задействовать настроенный модуль аутентификации. Для этого, acl в поле тип_отбора должен иметь значение proxy_auth, proxy_auth_regex или external с использованием переменной %LOGIN. И, естественно, для заданного acl необходимо иметь разрешение на доступ в параметре http_access.

Формат указания типа используемой аутентификации (формат использования параметра auth_param) следующий:

где, схема_аутентификации — одна из вышеуказанных схем (basic, digest. ), параметры_схемы — задают настройки указанной схемы и в разных схемах могут различаться, значения_параметров — в этом поле описываются значения параметров_схемы. К каждой схеме аутентификации могут использоваться сколько угодно разные внешние модули, вплоть до использования и самописных скриптов bash. Обычно при установке squid устанавливаются все необходимые модули согласно поддерживаемым схемам аутентификации. Описание их работы и настройки от разработчиков можно найти на этой странице .

Для дальнейшей настройки прокси-сервера я буду использовать «умолчательный» конфиг из коробки, в котором пока разрешен доступ только с петлевого интерфейса:

Basic — метод аутентификации в squid (NCSA)

Давайте рассмотрим простейший способ аутентификации, который существовал еще со времен протокола HTTP/1.0. Basic метод аутентификации основан на предоставлении клиентом (веб-браузером или другой программой) — учетных данных (имени и пароля) при запросе какой-либо страницы. При этом, имя пользователя, объединенное двоеточием с паролем кодируется в кодировку base64 и передается в http-запросе в поле Authorization. Например имя пользователя Mc.Sim и пароль 12345 в виде строки Mc.Sim:12345 будут переданы в кодированном виде: TWMuU2ltOjEyMzQ1 . Кодирование текста в кодировку base64 не является защитой. Фактически пароль передается в открытом виде. Единственным преимуществом этой схемы является то, что любой браузер? каким бы он старым не был, поддерживает данный вид аутентификации.

Давайте рассмотрим практический пример basic-аутентификации:

1. Клиент запрашивает страницу, которая требует проверки подлинности (в нашем случае — клиент обращается к серверу squid), но не указывает имя пользователя и пароль.
2. Сервер отвечает клиенту с кодом 407 (» Proxy Authentication Required»), в ответ включается список поддерживаемых методов аутентификации и заголовок (realm)
3. Клиент представит аутентификационную информацию (при этом браузер отобразит окно ввода логина/пароля и пользователь должен его ввести, либо отменить)
4. После того, как пользователь ввел имя и пароль, браузер (или другая программа), склеит имя пользователя и пароль двоеточием, закодирует символы в base64, подставит это значение исходных запрос в поле Authorization и направит серверу.
5. Сервер проверяет подлинность пароля и логина и предоставляет доступ.
6. Либо не предоставляет доступ, если данные не верны.

За хранение паролей в Basic аутентификации отвечает обычный текстовый файл, в котором хранятся стоки с логином и паролем в закодированном в base64 виде. Управление данным файлом удобно осуществлять с помощью утилиты htpasswd. В Debian/ubuntu данная утилита входит в пакет apache2-utils. В squid, по умолчанию, для реализации данного метода аутентификации используется хелпер /usr/lib/squid3/ncsa_auth, который проверяет соответствие логина и пароля в соответствии с заданным файлом и возвращает «OK» или «ERR» в бесконечном цикле. Синтаксис команды htpasswd следующий:

Для работы basic аутентификации в squid, необходимо задать параметр, указывающий на описанный нами хелпер, который взаимодействует с созданным нами файлом паролей. Кроме того, необходимо описать acl содержащий список пользователей, которые могут получить доступ к интернету (эти пользователи должны присутствовать в списке паролей), либо вместо пользователей указать значение REQUIRED, которое «включит» в созданный acl всех пользователей, прошедших аутентификацию. Ну и конечно необходимо разрешить доступ созданному acl с помощью параметра http_access. Живой пример:

Собственно, с данной конфигурацией уже вполне можно работать (не забудьте перезапустить squid). У параметра auth_param basic есть дополнительные настройки (например, количество одновременных соединений — auth_param basic concurrency n, время хранения/кэширования успешных авторизаций — auth_param basic credentialsttl 2 hours и др.), с которыми можно ознакомиться в squid.conf.

Кроме хранения паролей в файле, при basic аутентификации можно использовать еще великое множество источников информации о пользователе/пароле, например:

• LDAP — хелпер squid_ldap_auth
• PAM — хелпер pam_auth
• SASL — хелпер sasl_auth
• NIS — хелпер yp_auth
• MySQL — хелпер squid_db_auth
• RADIUS — хелпер squid_radius_auth
• и др

Digest — метод аутентификации в squid

Этот метод более защищен, нежели basic-аутентификация, т.к. использует MD5-шифрование для отправки пароля через сеть. Схема работы взаимодействия аналогична basic, за тем лишь исключением, что на 2-ом и последующих шагах в ответ сервера и ответы клиента в поля аутентификации добавляются некоторые дополнительные параметры и случайные значения, которые используются для шифрования пароля. Сам пароль передается в виде хэша, который шифруется и дешифруется с использованием случайного числа. Для создания файла паролей используется утилита htdigest, которая находится в пакете apache2-utils. Используется хелпер /usr/lib/squid3/digest_pw_auth с указанием файла паролей. Вообще, этот хелпер поддерживает файл паролей в открытом виде, вроде user:password. Может так же использоваться ldap для извлечения информации о пользователях, но опять же — низкий уровень безопасности. Для LDAP — хелпер /usr/lib/squid3/digest_ldap_auth.

NTLM — метод аутентификации в squid

Про протокол NTLM и его особенности и недостатки я рассказывал в первой статье о samba. В данной теме особенно делать упор на этот протокол не буду, ибо — небезопасен. Для проверки подлинности используется хелпер /usr/lib/squid3/ntlm_auth. Данный вид аутентификации работает в браузерах IE, Mozilla, Opera, Crome.

Negotiate — метод аутентификации в squid

Теперь перейдем к самому интересному. Итак, Kerberos — аутентификация в squid в домене на Windows 2008 R2. Проверять валидность пользователя через Kerberos можно разными путями, например многие советуют использовать SAMBA+Winbind, но нам на сервере лишние службы не нужны, поэтому будем использовать другой способ — пакет krb5-user и файл krb5.conf. Пакет krb5-user и его зависимости содержит утилиты, разработанные Massachusetts Institute of Technology (MIT). Существует еще версия, разработанная hedimal, но мне с ней работать не приходилось. Способ аутентификации на основе MIT Kerberos на примере NFS я рассматривал в статье использование AD на Windows 2008 R2 как KDC для NFS, которую очень желательно почитать перед тем как приступать к текущему разделу. Большая часто теории — в указанной статье. Здесь я лишь частично опишу необходимые действия, отличные от NFS.

Схема наших действий примерно следующая:

1. Настроить squid и проверить работоспособность без Kerberos с доступом по IP, либо basic-аутентификация.
2. Настроить Kerberos

1. Предварительная настройка DNS и контроллера домена.
2. Настройка синхронизации времени (на основе демона ntpd)
3. Настроить и проверить Kerberos на идентификацию пользователя без ключевого файла krb5.keytab.
4. Создать ключевой файл krb5.keytab на KDC (контроллер домена Windows 2008 R2)
5. Настроить и проверить работу Kerberos для авторизации через krb5.keytab и корректность созданного keytab-файла.

3. Настроить squid на проверку подлинности через Kerberos.
4. Настроить веб-браузеры на Kerberos аутентификацию.

Давайте подробней разберем каждый шаг.

Исходные данные для организации NEGOTIATE — схемы аутентификации

• домен — DOMAIN.LOCAL
• DNS-имя контроллера домена — DC.DOMAIN.LOCAL
• IP-адрес контроллера домена — 10.0.0.4
• прокси-сервер squid
  • DNS-имя SQUID сервера — SQUID.DOMAIN.LOCAL
  • IP-адрес SQUID сервера — 10.0.0.10

  1. Настроить squid и проверить работоспособность без Kerberos с доступом по IP, либо basic-аутентификация.

  Данный пункт был реализован согласно приведенных в заголовке ссылок — ранее. Но есть некоторые нюансы конфигурирования сетевой подсистемы для корректной работы с Kerberos. Необходимо обязательно правильно настроить файлы /etc/hosts, /etc/hostname, /etc/resolv.conf, ну и конечно /etc/network/interfaces. (приведенные настройки рассмотрены для Debian/Ubuntu, но если учесть особенности другого дистрибутива, то общая схема настройки будет вполне пригодна)

  2. Настройка Kerberos

  2.1. Предварительная настройка DNS и контроллера домена.

  Для корректной работы Kerberos необходимо иметь корректные прямые (A) записи и соответствующие обратные (PTR) записи для сервера squid.

  2.2. Настройка синхронизации времени

  Настройку синхронизации времени я описывал в статье о NFS в Windows AD. Здесь лишь кратко скажу, что я использую для этих целей NTP-сервер (пакет ntp) и следующий конфиг:

  2.3. Настроить и проверить Kerberos на идентификацию пользователя без ключевого файла krb5.keytab.

  Данный шаг так же описан в статье о NFS в Windows AD, здесь он абсолютно идентичен.

  2.4. Создать ключевой файл krb5.keytab на KDC (контроллер домена Windows 2008 R2)

  Далее, необходимо создать кейтаб-файл на контроллере домена (файл ключей, который будет использоваться для взаимодействия с Active Directory). Вся необходимая теория опять же есть в статье о NFS — создание keytab. Для squid команда создания keytab файла будет выглядеть так:

  Итого, мы получили keytab в каталоге C:\tmp\ — squid.keytab. Теперь этот файл ключей Kerberos необходимо БЕЗОПАСНО скопировать на сервер squid, например чрез WinSCP и приступить к следующему шагу. Так же нужно задать права кейтабу.

  2.5. Настроить и проверить работу Kerberos для авторизации через krb5.keytab и корректность созданного keytab-файла.

  Допустим, лежит наш keytab в /etc/squid3/squid.keytab, давайте проверим корректность работы данного кейтаба с текущей ОС:

  Что мы сделали в текущем листинге? Утилитой kinit мы инициировали получение и положили в кэш билет от KDC для SPN-записи HTTP/squid.domain.local с использованием ключа (т.е. не пароля , параметр -k) размещение которого задано с помощью параме. Для/emтра -t /etc/squid3/squid.keytab. Параметр -V заставляет утилиту выводить сообщение при удачной аутентификации. Далее, с помощью klist мы просматриваем полученный билет, который размещен в кэше. С помощью kdestroy мы уничтожаем все, что есть в кэше. Далее, мы ограничивает права доступа к нашему кейтабу, тем самым разрешаем доступ только пользователю, под которым работает сквид. АХТУНГ. Если на данном этапе kinit выдал ошибки, то далее настраивать смысла нет, ибо Kerberos клиент работает не корректно. Необходимо избавиться от ошибок.

  3. Настройка squid на проверку подлинности через Kerberos в домене Windows 2008 R2.

  Для того чтобы сквид знал, какой кейтаб использовать, ему нужно указать, где он лежит. Для этого нужно создать и заполнить файл /etc/default/squid3 следующим содержимым (задать переменную, хранящую путь к кейтаб файлу, которую читает сквид):

  Так же, необходимо в squid.conf настроить схему аутентификации, для этого нужно добавить следующие строки:

  В некоторых конфигурациях в «сети» приводятся примеры без указания параметра -s и SPN, но у меня такая конфигурация не заработала. Так же, не забываем о наличии строк, разрешающим доступ для авторизованных пользователей:

  Примечание: вместо SPN можно использовать значение GSS_C_NO_NAME, в данном случае, squid будет использовать любой (какой? в какой последовательности?) SPN из keytab файла. Строка будет выглядеть так: <. >ate program /usr/lib/squid3/squid_kerb_auth -s GSS_C_NO_NAME (спасибо за дополнение комментатору selivan)

  На этом можно считать настойку сквида законченной (не забудте сделать рестарт сквида). Если необходимо пускать не в всех пользователей в интернет, а только избранных, то в acl необходимо указать имя пользователя в том формате, в котором squid распознает пользователя. Этот формат можно посмотреть в логе access.log. Например для нашего случая имя пользователя имеет следующий вид:

  то есть имя пользователя имеет формат имя_пользователя@ОБЛАСТЬ_ДОМЕНА. При этом, как показала практика, регистр букв имеет значение , то есть если в acl указать имя пользователя t E st2@DOMAIN.LOCAL или test2@DOMAIN. local , а в AD он заведен как test2 и область домена в верхнем регистре, то доступ пользователю предоставлен не будет. То есть нужно быть внимательным при указании пользователя в acl. Так же, можно задать список пользователей, перечислив их в отдельном файле и указав этот файл как значение для acl, например:

  Кроме данного способа, есть возможность предоставить доступ пользователей к интернету на основе членства в доменных группах. Но для данной задачи используется отдельный хелпер и список доступа в формате external_acl и хелпер /usr/lib/squid3/squid_ldap_group. В сети можно найти много примеров. Конфигурацию на основе доменных групп я постараюсь рассмотреть в следующих статьях.

  4. Настроить веб-браузеры на Kerberos аутентификацию в squid.

  Собственно, настройка браузеров для SQUID заключается в использовании FQDN-имени в адресе прокси-сервера вместо IP-адреса. То есть делаем все по инструкции Настройка адреса прокси через GPO в Windows Server 2008 R2, но адрес прокси указываем не 10.0.0.10, а squid.domain.local. Корректная работа с Kerberos у меня получилась только в браузерах IE старше 7 версии, Firefox и Chrome. Про IE версии ниже 7 версии можно почитать статью от microsoft .

  После попытки доступа мы видим в логе access.log заветные строки:

  Финальный вид настроек в squid.conf

  Таким образом, мы требуем от клиента — Kerberos (negotiate) аутентификации, если клиент не принадлежит домену, то он должен аутентифицироваться через Basic аутентификацию. Это очень удобно, когда всем доменным пользователям предоставляется доступ по их доменной учетной записи, а «гостям», например с ноутбуками — выдаем логин/пароль для basic аутентификации. Эти логины/пароли храним в файле /etc/squid3/squidbasicusers. Список всех, кому разрешаем доступ мы храним в файле /etc/squid3/usersallow.

  Траблешуттинг

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

  Для корректной работы kerberos необходимо иметь открытый доступ для исходящих пакетов на tcp/dst-порт 88. Как это сделать, описано в статьях об iptables.

  Для диагностики SQUID и Kerberos можно в строке

  добавить ключ -d — это заставит хелпер быть более разговорчивым. При ошибках аутентификации сообщения будут появляться в логе /var/log/squid3/cache.log. Например, когда я неверно указал адрес прокси в браузере (указад ip вместо DNS FQDN), то в лог сыпались вот такие ошибки:

  Резюме

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

  Что еще почитать

  Примеры использования LDAP групп в AD:
  http://ru.gentoo-wiki.com/wiki/Настройка_авторизации_SQUID_в_Active_Directory_по_протоколу_LDAP
  http://www.lissyara.su/?id=2101

  Использование Kerberos в Web-сервере
  ttp://www.grolmsnet.de/kerbtut/

  Интересный нюанс работы squid и в целом аутентификации (первый и последний пост):
  http://forum.ru-board.com/topic.cgi?forum=8&topic=11275

  Upd 2012.04.08: добавил книгу Squid Proxy Server 3.1 Beginner’s Guide
  Upd 2013.10.26: добавил инфу о GSS_C_NO_NAME

  Похожие публикации:

  1. Как настроить поиск в outlook
  2. Как подключить сканер штрих кода netum
  3. Как установить visual studio code на ubuntu
  4. Почему не подключается континент ап