Comments 46
Спасибо за статью. Один вопрос — вы не пробовали подружить squid и selinux? Может не стоит его так на корню сразу рубить?
Тут кроме безопасности еще бывает вопрос производительности. Научить — да, можно. Хватит ли сервера — вопрос. Я с этим столкнулся на web-серверах: с включенным selinux производительность php ниже чем на десктопе разработчика, несмотря на платформу, ядра и память…
В общем случае, безусловно, вы правы — надо настраивать, пользуясь например CentOS wiki
Это понятно, что каждый запрос к http серверу пройдет через политики selinux, и да, возможно, будет наблюдаться снижение производительности. Но тут уже кому что. Если ваш веб-сервер смотрит наружу, то я бы не стал отключать selinux даже в угоду производительности системы. А если это какой-то корпоративный портал и вы уверены в своих пользователях, то здесь уже все на свой страх и риск.
К сожалению, не было достаточно времени вплотную подойти к данному вопросу. В ходе написания статьи я поднял дополнительную виртуалку со всеми параметрами как в статье. В ней попробую включить selinux, и в случае успешной настройки, я поправлю статью.
Игры с selinux это отдельная и интересная тема. Вам точно понравится.
Да, было довольно-таки интересно! Включил selinux и поправил статью, все работает
А зачем у вас в конфиге Kerberos что-то ниже RC4-HMAC? И зачем учетка сквида генерит кейтаб с RC4-HMAC, если домен с поддержкой AES?
Кейтаб на сквиде нужен для аутентификации самого сквида в AD.
А зачем ему кейтаб, если можно настроить аутентификацию сквида в AD через логин\пароль?
Сквиду в AD только и надо, что права на чтение юзеров и групп.
Потому что без этого (регистрации сквида в AD как сервиса с соответствующим SPN) вся схема прозрачной Kerberos-аутентификации не заработает.
А керберос между прокси и клиентом как будет? Мы хотим, чтобы клиенты могли использовать SSO при подключении к прокси-серверу?
А керберос в этом случае не будет. Необходимо будет вводит вручную доменный логин пароль, хотя бы один раз.
Именно. А в варианте автора — не нужно вообще. Зашёл в систему — получил tgt. Веб-клиент к прокси — система автоматически получает тикет для него и пользователю снова вводить доменный пароль не надо.
Правильно ли я понимаю, что для работы этой строчки
https_port 10.0.0.10:3129 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 connection-auth=off cert=/etc/squid/squidCA.pem

в клинских машинах необходима установить сертификат выше как корневой сертификат?
Или он нужен для прокси сервера, чтобы squid с начало посмотрел заголовки http, далее отправил клиенту запрошенный контент?
Да, он нужен только для самого squid.

Нет необходимости устанавливать сертификат на клиентах.
Он указан, и генератор сертификатов (sslcrtd_program) и место их хранения указанО, но эта дорожка с автоматической генерацией и подписью всех сертификатов своим CA просто банально не включена на том порту, который указан в wpad.

Если вы из этой конфигурации хотите сделать перешифрование (настоящий MitM), нужно только поменять следующее:

http_port 10.0.0.10:3130 options=NO_SSLv3:NO_SSLv2

на

http_port 10.0.0.10:3130 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 connection-auth=off cert=/etc/squid/squidCA.pem generate-host-certificates=on

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

UPD: для указанной вами https_port надо, но похоже конфиг wpad у автора такой, что на https_port никого не направляет.
Скажите, чем вы руководствовались при настройке Kerberos-клиента?
Зачем у этих параметров «dns_lookup_kdc», «dns_lookup_realm» установлено значение «no»?
Настоятельно рекомендую разобраться с документацией и не писать глупости. Эти перлы в конфиге уже не первый год тянутся из статьи в статью, как вонь за народным ополчением.
Если разбираться лень, то просто удалите krb5.conf и все параметры примут значения по умолчанию, которые более адекватны.

ЗЫ: Прекратите выкапывать виндовый ktpass. Для ввода *nix-машины в AD используйте msktutil. Она не требует создания связанной пользовательской учётной записи, позволяет удобно добавлять SPN, а так же обновлять пароль учётной записи.
Спасибо большое за правильные замечания. К сожалению, я уже точно не могу вспомнить почему я привел конфиг krb5.conf именно к такому виду. Если не изменяет память, в других вариациях были проблемы с авторизацией, и только с такими параметрами работает нормально.

З.Ы. как появится свободное время, обязательно протестирую варианты без krb5.conf и использование mskutil.
Ну а что вы хотите от простых смертных, когда эти настройки, например, сидят даже в официальной wiki по самбе? :) Ситуация вообще чудесная — https://lists.samba.org/archive/samba-technical/2012-May/083634.html. «Да, у нас лажа, но эти настройки у нас не используются, потому нам пофиг и лажу исправлять не будем».

> Она не требует создания связанной пользовательской учётной записи

Переформулирую (чтобы читатели не подумали, что запись не создаётся вообще) — создаёт эту запись сама.
> Переформулирую (чтобы читатели не подумали, что запись не создаётся вообще) — создаёт эту запись сама.

Чтобы уж точно никого не запутать, переформулирую ещё раз. Ktpass создаёт keytab для предварительно созданной пользовательской учетной записи, msktitil же создаёт учетную запись компьютера и keytab для неё.
В большой AD (как у меня) могут использоваться AD Sites — для распределения нагрузки на разные сервера согласно сетевым адресам клиентов. Windows знает о существовании AD Sites и может выдать нужный kdc для клиента. Linux же полагается только на то, что вернёт dns запрос, поэтому запрос авторизации может уйти на удалённый kdc к которому нет доступа из подсети клиента, и тогда авторизация зависнет и потом завершиться неудачно.
Видимо поэтому в большинстве примеров конфигов dns_lookup_kdc=no
У меня тоже не получилось заставить linux обращаться только к kdc расположенных в локальном сайте и пришлось прописать эту опцию.
Если подскажите как заставить linux обращаться к kdc только в своей подсети буду благодарен.
Dns запрос, в моём случае, всегда возвращает полный список всех kdc домена.
В данной схеме *nix-машина является клиентом или предоставляет сервис? Если второе, то после ввода машины в домен сетевой доступ к KDC больше не нужен, так как по архитектуре протокола сервер к KDC самостоятельно не обращается — вся необходимая информация содержится в билете пользователя.
Проблемы могут возникнуть только в случае обновления пароля учётной записи, которое по умолчанию не используется и требует дополнительной настройки.

Процесс обнаружения ближайшего контроллера домена (читать тут и тут) выполняется с помощью LDAP (или даже CLDAP) протокола, а потому в «чистом» Kerberos не возможен. Если есть острая необходимость, можно установить на сервер пакет Samba и настроить её на использование внешнего keytab. Так же я находил упоминания, что библиотеки MIT Kerberos отдают предпочтение KDC в одной подсети с клиентом, но подтвердить не могу, надо смотреть в исходниках.

На самом деле, ограничивать сетевой доступ к контроллерам в разных сайтах — плохая идея. Могут вылезти грабли даже на Windows-системах. В частности при переезде машины из одного сайта в другой.

К сожалению, в большинстве примеров dns_lookup_kdc=no из-за того, что настройка производится бездумно методом копипасты.

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

Согласен, может быть множество причин для отключения автообнаружения. Именно для этого и предусмотрена возможность менять эти значения в конфигурационном файле. Суть моего комментария в том, что в большинстве статей этот параметр отключен (да не только этот параметр, а весь конфигурационный файл — сплошная магия) потому, что «у всех так». Ниже вы написали, что гораздо продуктивнее руководствоваться принципом «понимаю, что делает каждая строка» и с этим я полностью согласен.
Не было проблем с java апплетами и Kerberos авторизацией? В апплетах похоже работает только ntlm авторизация. Java в браузере, конечно уже мертва, но у меня есть один государственный сайт, который работает только через апплеты. Приходится выкручиваться.
Если не изменяет память, у интернет-банка ВТБ используется java, и с ним проблем не возникало. Не могли бы вы в сообщить государственный сайт, который вас особенно интересует? Можно личным сообщением
У меня на сквиде с керберосом было, натыкался.
То, что я раскопал — ява может в керберос, но это должно быть предусмотрено разработчиком апплета. В моем случае я просто дописал правило, чтоб на сайты нужных банков всех пускало без авторизации.
Правильно ли использовать:
if (isInNet( host, «192.168.0.0», «255.255.255.0») ||
isInNet( host, «10.0.0.0», «255.255.255.0») ||

Лучше использовать с резолвом: isInNet(dnsResolve(host), «10.0.0.0», «255.255.255.0»))
Признаюсь честно, я не сильно подкован в данном вопросе. Объясните пожалуйста, почему ваш вариант лучше
Я полагаю, brainfair не уверен что isInNet() самостоятельно отрезолвит параметр host, если в нем будет передано доменное имя вместо IP-адреса.
Работать будет и так и так, но наверно я тоже неправильно поправил, на самом деле лучше всего сначала отрезолвить host в ip адрес в отдельную переменную например hostip и уже потом проверять его в isInNet, в противном случае у вас будет замедление работы так как в каждой проверке будет заново резолвиться имя в ip, и соответственно чем больше у вас isinnet тем медленнее это будет работать.

Тоесть в примере:
hostip=dnsResolve(host);
if (isInNet( hostip, «192.168.0.0», «255.255.255.0») ||
isInNet( hostip, «10.0.0.0», «255.255.255.0») ||

Это будет так только если ни в браузере, ни в системе нет своего кэша DNS — иначе время повторного резолвинга будет пренебрежимо мало. А в приведенном случае, имхо, даже кэширующий DNS-сервер в локалке спасёт.
Небольшое дополнение: тут проскальзывала публикация, описывающая как, контролируя .pac-файл, вытаскивать URL посещенной страницы независимо от шифрования. если коротко, кодируем полученный в параметрах url и делаем dnsResolve() через выделенный поддомен нашего домена (скажем, codedurlhere.filter.domain.tld), который контролируется отдельным нестандартным DNS сервером (например, логирующим все запросы и отдающим в ответ 127.0.0.1).
Конечно, решение извращенное, и овчинка может не стоить выделки, но по идее узнать полный URL таким образом должно быть реально.
Автор, зачем у вас в конфиге указаны http_port intercept и https_port с MitM, если ваш wpad всё равно направляет всех на http_port без intercept, да и вообще судя по описанию у вас нужна аутентификация по AD (никакого прозрачного прокси), и явно сказано, что MitM использоваться не должен?
Стараюсь пользоваться принципом «работает — не мешай», но сегодня поразмыслив, все же убрал данные строки. Без них тоже работает как надо. Конфиг поправил
А вот теперь вам и sslcrtd_program не нужна. Эта строка указывает команду, используемую для автогенерации сертификатов для MitM, а его же больше нет. И файлик с корневым сертификатом ЦС+ключом не нужен по этой же причине.

Гораздо продуктивнее руководствоваться принципом «понимаю, что делает каждая строка».
В отчетах вместо ip-адресов, указаны принципалы пользователей. Проще говоря, список в таком формате:
i.ivanov@example.ru
s.sidorov@example.ru
А вот кто расскажет, как со скайпом в случае прокси с керберосом?
Звонки работают?
Как будут результаты — дай знать, плз., или сюда, или в личку.
У меня не работает ни в какую. Когда скайп работает через прокси — он пытается использовать STUN для разговоров, если я все правильно понял.
Only those users with full accounts are able to leave comments. Log in, please.