squid+LDAP - помогите вспомнить где ..

[Александр Читалкин]

Слишком много чувствительных данных передается по сети. Опять же, как работает аналог ClientTrust на локальной машине? Что у него спрашивает прокси? Стандартная схема:
1) Коннект на прокси
2) Запрос "а ну-ка, неизвестный IP, назови свое имя в каталоге!"
3) Прокси получает ответ и хелпером спрашивает у eDir, позволено/непозволено
4) В случае успеха/неуспеха самописный хелпер отдает yes/no
5) Сквид выполняет, разрешая или запрещая доступ
Недостатки, какими они мне видятся. Взаимодействие с локальной машиной происходит в открытую. Любая программа весом в 50Кб, написанная прямыми руками, откроет сокет, который будет на все вопросы от прокси высылать имя заведомо разрешенного пользователя. Это решение мало того небезопасно, оно еще и стандартно - городушки гордить с хелперами для сквида просто не было смысла. Сквид может стандартно взаимодействовать по протоколу ident с клиентом. Для этого только для клиента пишется небольшая програмулина, который слушает ident порт и передает реквизиты текущего пользователя. Помнится, лично сваял к сквиду такое за 15 минут, совершенно рабочий вариант, повторить который сообразительному "злоумышленнику" не составит труда.

Далее... я так понимаю, самописный хелпер сквида, кроме того как отдает сквиду резолюцию после проверки в eDir, модифицирует и iptables. Это хорошо, когда необходимо разрешить клиенту доступ, создав для него разрешаюие правило, и снимать с него статистику. Но как его запрещать? В realtime "выловить" нахалов все равно не получиться, кроме случая, когда работаем во fbsd и умеем пользоваться возможностями ipfw.

В итоге имеем две дыры - утечки трафика и тривиальная подделка clienttrusta, ведь упомяналось именно использование аналога программы от Novell.

Лично мне гораздо более интересно решение OpenVPN+Radius на основе сертифкатов. Достаточно одныжды установить на машину клиентский "доверенный" сертификат, и запускать OpenVPN клиент по startup-скрипту, как мы получим практически готовое решение SSO, которое можно использовать еще и для доступа к защищенным веб-узлам или строить на этой основе аутентификацию на всяческих CMS. Мной такое решение было успешно реализовано в сети из 500 рабочих станций и ActiveDirectory.

сквид видит какой IP-ик обращается и лезет eDir по LDAP

Видит, но не отадет. Хелперу аутентификации передается только username/pass в stdin, в ответ на который приходит либо "да", либо "нет".

[Михаил Григорьев]

Ваше предложение - Free или за деньги ?
Если Free- откуда взять ?
Если за деньги - сколько стоит ?

Решение БЕСПЛАТНОЕ!!!!

Могу скинуть все имеющиеся конфиги, а вот сможите ли вы по этим конфигам все настроить это уже от вас зависит, я по мере свободного времени могу проконсультировать!

Могу внедрить данное дело у вас в компании, внедрение конечно не бесплатно, сами понимаете, любой чужой труд должен оплачиваться. В этом случае от вас нужно будет тех. задание.

Лично мне гораздо более интересно решение OpenVPN+Radius на основе сертифкатов.

Интересное конечно решение, я про такое тоже думал, но с сертификатами есть тоже свои замороки. И еще момент, украв сертификат мы сможем вытворять что захотим, а это не есть гуд!

[Иван Левшин aka Ivan L.]

Слишком много чувствительных данных передается по сети.

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

Опять же, как работает аналог ClientTrust на локальной машине? Что у него спрашивает прокси? Стандартная схема:
1) Коннект на прокси
2) Запрос "а ну-ка, неизвестный IP, назови свое имя в каталоге!"
3) Прокси получает ответ и хелпером спрашивает у eDir, позволено/непозволено
4) В случае успеха/неуспеха самописный хелпер отдает yes/no
5) Сквид выполняет, разрешая или запрещая доступ

В первом приближении - да, конечно. Конкретно тебе расскажет Пашка, когда здесь появится.

Недостатки, какими они мне видятся. Взаимодействие с локальной машиной происходит в открытую. Любая программа весом в 50Кб, написанная прямыми руками, откроет сокет, который будет на все вопросы от прокси высылать имя заведомо разрешенного пользователя. Это решение мало того небезопасно, оно еще и стандартно - городушки гордить с хелперами для сквида просто не было смысла. Сквид может стандартно взаимодействовать по протоколу ident с клиентом. Для этого только для клиента пишется небольшая програмулина, который слушает ident порт и передает реквизиты текущего пользователя. Помнится, лично сваял к сквиду такое за 15 минут, совершенно рабочий вариант, повторить который сообразительному "злоумышленнику" не составит труда.

Кгхм... Александр... Я, конечно, все понимаю... Но с чего ты взял, что то, что тебе в голову приходит - совершенно ни в каком случае не может прийти в голову кому-то еще? Изначально задача поставлена так, что трафик между клиентом и демоном должен быть зашифрован - именно для того, чтобы избежать описанной тобой ситуации

Далее... я так понимаю, самописный хелпер сквида, кроме того как отдает сквиду резолюцию после проверки в eDir, модифицирует и iptables. Это хорошо, когда необходимо разрешить клиенту доступ, создав для него разрешаюие правило, и снимать с него статистику. Но как его запрещать? В realtime "выловить" нахалов все равно не получиться, кроме случая, когда работаем во fbsd и умеем пользоваться возможностями ipfw.

Узнаю подход "я все знаю больше и лучше всех" Ты, видимо, удивишься - но "нахалы" отлавливаются и превышение по трафику составляет не более 100 Кб. Файрволлом можно как разрешить, так и запретить доступ.

В итоге имеем две дыры - утечки трафика и тривиальная подделка clienttrusta, ведь упомяналось именно использование аналога программы от Novell.

Ну-ну Лично предоставлю тебе возможность воспользоваться дырой через "тривиальную подделку". А утечка - копеешная, в общих масштабах потребления трафика практически не играющая роли.

[Александр Читалкин]

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

Кгм... Помню, нЭвопрос. И простой снифф сети в принципе, твой слова подтверждает. Кстати... меня всегда терзали смутные сомнения по поводу того, а безопасен ли Novell ClientTrust? Твои слова "да, наверное, скорее да, чем нет" уверенность в этом не внушали. Увы, контенгент пользователей у тебя таков, что некому эту безопасность на чистую воду выводить (поправь, если ошибаюсь). Думаю, потому и эксплуатировалось это решение без эксцессов на момент моего пребывания в НИРХТУ.

Кгхм... Александр... Я, конечно, все понимаю... Но с чего ты взял, что то, что тебе в голову приходит - совершенно ни в каком случае не может прийти в голову кому-то еще? Изначально задача поставлена так, что трафик между клиентом и демоном должен быть зашифрован - именно для того, чтобы избежать описанной тобой ситуации

Изначально задача поставлена так, что трафик между клиентом и демоном должен быть зашифрован

Ну... Откровений я вроде бы в своем сообщений никаких не делал. Описанное решение "пришло в голову" задолго до меня многим, и вполне успешно реализовано. Пример с ident это подтверждает (люди аж целый протокол придумали, даже RFC для него есть), поэтому если уж и изобретать велосипед - то для того, чтобы избежать вопиющей небезопасности подобного подхода. А что касается шифрования... Оно сводиться на нет, если исходные нешифрованные данные заранее известны. Если аналог ClientTrust передает демону, допустим, "ivan.cit.nirctu", пусть даже закрытом виде - не составит большого труда "фальшивке" его также предварительно пошифровать

Узнаю подход "я все знаю больше и лучше всех" Ты, видимо, удивишься - но "нахалы" отлавливаются и превышение по трафику составляет не более 100 Кб.

Благодарю за критическю оценку, но думаю, к вопросу обсуждения это относиться весьма опосредованно. Простая логика - оперативно реагировать на трафик можно только в случае анализа и подсчета всего потока в реальном времени. Если реализация именно такая - тогда без комментариев. Если снимать статистику периодически, то утечки неизбежны, и чем больше клиентов и шире труба, тем медленнее будет работать ее сборщик. Я не утверждал, что эти утечки эти должны быть огромными.
Простой пример сборщика на перле, написанного мной "на коленке" просто ради спортивного интереса. Схема его работы была такова
1) Запускаемся по крону каждые 30 секунд (можно также сделать демон, запускающий процедуру проверки каждые n секунд).
2) Делаем запрос в некую БД на список квот
2) Снимаем показатели со счетчиков ipfw (дело было под fbsd, от iptables в данном случае принципиальных отличий нет)
3) Если счетчик > квота, добавляем правило на дроп
4) В конце каждого месяца удаляем все дропы
На 10 клиентах работало великолепно. НА 50 клиентах 30 секунд уже не хватало, приходилось увеличивать интервал крона, а это увеличивает и утечку. Нет, конечно, решение далеко от идеала, и призвано было скорее на опыте выявить соотношение мб/сек утечки при скорости подключение 10Мбит/с.

Файрволлом можно как разрешить, так и запретить доступ.

Адназначно Очевидно, для этого есть разрешающие и запрещающие правила, соответственно.

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

нЭвопрос Зайду как-нибудь в гости, если ты не против, главное выдели мне машину с сетью, стетоскопом и Delphi

По поводу разрыва коннекта - попробуй использовать вместо правил DROP правило REJECT на 3128 порт (или какой там использует у тебя squid).

[Андрей Тр. aka RH]

Лично мне гораздо более интересно решение OpenVPN+Radius на основе сертифкатов.

Интересное конечно решение, я про такое тоже думал, но с сертификатами есть тоже свои замороки. И еще момент, украв сертификат мы сможем вытворять что захотим, а это не есть гуд!

Кстати, мне решение с сертификатами тоже интересно. А что, разве они не могут быть защищены паролями и так запросто добавляются и используются на новом месте ?

ИМХО вариант с "клиенттрастом" неважен тем, что приходится ставить какой-то "клиент" ( т.е. этот самый клиенттраст ) - со всеми вытекающими ( к примеру, его ж потом как-то надо будет обновлять .. ). А хочется обойтись уже тем, что есть ( на клиентах - т.е. браузером и ОС ). Мне проще на серверах что-то нагородить, т.к. с точки зрения управления и поддержки это дешевле.

[Александр Читалкин]

Интересное конечно решение, я про такое тоже думал, но с сертификатами есть тоже свои замороки. И еще момент, украв сертификат мы сможем вытворять что захотим, а это не есть гуд!

Сертификат x.509 практически невозможно украсть с клиентской машины, поскольку при экспорте сертификата его закрытый ключ не экспортируется. Также, файл PKCS#12 (ключ+сертификат) защищен паролем, который необходим при инсталляции на клиентскую машину.

Кстати, кроме сеансового VPN соединения существует также решение IPsec, которое еще более "прозрачно", достаточно лишь однажды настроить машину (импортировать сертфикаты корня и пользователя, создать ipsec-политику) чтобы получать или не получать доступ к серверу (шлюзу, прокси). Кстати, первоначальную настройку (за исключением импорта личного сертификата) думаю можно провести автоматически, с использованием соответствующих средств от той же фирмы Novell. Либо запускать startup скрипт, который производит настройку при необходимости. Недостаток ipsec - трудно установить факт начала и окончания работы, а значит посчитать трафик и отсечь при необходимости.

Однако... у перечисленных способов есть маленькая загвоздка Проявляется она, если на клиенте используется так называемая "Windows XP Corporate Edition", есессно, пиратская Попытка завести на ней ipsec провалились - причем по непонятным причинам. Он просто не работал, и все. Перекопав массу инфы и выслушав несколько полезных наводок, я добрался до исполняемого файла lsass.exe. Дизассемблировав этот файл, оказалось, что доблестные пираты так усердствовали в отломе механизмов защиты XP и активации, что очень основательно перелопатили его, сделав винду практически непригодной к работе с ipsec.

[Михаил Григорьев]

Сертификат x.509 практически невозможно украсть с клиентской машины, поскольку при экспорте сертификата его закрытый ключ не экспортируется. Также, файл PKCS#12 (ключ+сертификат) защищен паролем, который необходим при инсталляции на клиентскую машину.

MD5 тоже говорили что надежен, но нашлись люди кот. сломали
Сломать RSA512 тоже говорили невозможно, но недавно сломали.
На очереди RSA1024...

дело даже не в том что можно сломать или нет, у вас 5000 машин по всей стране, вы заставите службу ИТ бегать по всем им и ставить сертификаты? знаю что на этот счёт есть решение, но стоит ли офчинка выделки.

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

я конечно утрирую, но какой смысл заморачиваться с зашитой когда как в мультике тётя Маша закрывает картонную дверь в банке, а ключь ложить рядом под коврик!

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

Еще один любопытный факт из жизни! Недавно у нас в городе появился оператор CDMA2000 - СкайЛинк, дык эти чуды пытались меня заверить что разговоры невозможно подслушать. После того как я сказал одно единственное слово их спецу мне тут же подарили ручку и флажок и ненавязчиво сказали чтобы я отошёл и не пугал посетителей! Увы но большое ухо ФСБ слушает всех, и операторов связи и провайдеров и.... Вот вам и безопасность!

[Иван Левшин aka Ivan L.]

Кгм... Помню, нЭвопрос. И простой снифф сети в принципе, твой слова подтверждает. Кстати... меня всегда терзали смутные сомнения по поводу того, а безопасен ли Novell ClientTrust? Твои слова "да, наверное, скорее да, чем нет" уверенность в этом не внушали. Увы, контенгент пользователей у тебя таков, что некому эту безопасность на чистую воду выводить (поправь, если ошибаюсь). Думаю, потому и эксплуатировалось это решение без эксцессов на момент моего пребывания в НИРХТУ.

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

А что касается шифрования... Оно сводиться на нет, если исходные нешифрованные данные заранее известны. Если аналог ClientTrust передает демону, допустим, "ivan.cit.nirctu", пусть даже закрытом виде - не составит большого труда "фальшивке" его также предварительно пошифровать

Блестящее теоретизирование всегда было твоей сильной стороной Это как, интересно, ты сможешь подсунуть фальшивку, не зная алгоритма шифрования и не имея доступа к ключам, а также не зная - что в принципе и как передается серверу с клиента? Можно, конечно, перехатить именно посылаемый пакет и его отправить повторно - только подозреваю, что структура пакета перманентно меняется (как именно - Новель не признается), так что и подобный способ не канает.
Рекомендую все же внимательнее изучить обсуждаемый предмет - ибо подход с позиций "а олени лучше" вряд ли можно назвать грамотным.

Простая логика - оперативно реагировать на трафик можно только в случае анализа и подсчета всего потока в реальном времени. Если реализация именно такая - тогда без комментариев. Если снимать статистику периодически, то утечки неизбежны, и чем больше клиентов и шире труба, тем медленнее будет работать ее сборщик. Я не утверждал, что эти утечки эти должны быть огромными.
Простой пример сборщика на перле, написанного мной "на коленке" просто ради спортивного интереса. Схема его работы была такова
1) Запускаемся по крону каждые 30 секунд (можно также сделать демон, запускающий процедуру проверки каждые n секунд).
2) Делаем запрос в некую БД на список квот
2) Снимаем показатели со счетчиков ipfw (дело было под fbsd, от iptables в данном случае принципиальных отличий нет)
3) Если счетчик > квота, добавляем правило на дроп
4) В конце каждого месяца удаляем все дропы
На 10 клиентах работало великолепно. НА 50 клиентах 30 секунд уже не хватало, приходилось увеличивать интервал крона, а это увеличивает и утечку. Нет, конечно, решение далеко от идеала, и призвано было скорее на опыте выявить соотношение мб/сек утечки при скорости подключение 10Мбит/с.

Мы обходимся без крона и "простая логика" нам вполне доступна. Я вроде писал, что работа с потоком ведется в реальном времени. Наше решение пока далеко от идеала - но оно работает. И, думаю, заработает таки...

Файрволлом можно как разрешить, так и запретить доступ.

Адназначно Очевидно, для этого есть разрешающие и запрещающие правила, соответственно.

Хех... Ты бы все же обращал внимание на то, что пишешь. Объяснять прописные истины здесь не требуется

По поводу разрыва коннекта - попробуй использовать вместо правил DROP правило REJECT на 3128 порт (или какой там использует у тебя squid).

Я в курсе, каким правилами прописывается iptables Александр, потрудись говорить по делу, а не блистать знанием прописных истин. Речь шла о том, что валится сетевая служба на клиентской стороне при разрыве соединения (пробовали и DROP, и REJECT) либо сервак пропускает трафик.

Что касаемо разрыва соединения на порт прокси - мне не надо его рвать. Мне надо, чтобы прокси отвечал "403 Доступ запрещен" ТАк что не канает.

[zaki]

Что касаемо разрыва соединения на порт прокси - мне не надо его рвать. Мне надо, чтобы прокси отвечал "403 Доступ запрещен" ТАк что не канает.

Лучше смотри в сторону PAM +Squid ....

[Александр Читалкин]

Приходи, регистрируйся и вперед с песнями Правда, как ты юникастовый трафик на коммутаторе перехватывать будешь "банальным снифером" - я с удовольствием посмотрю.

Достаточно просто Я запущу на этой машине ваш аналог ClientTrust'а, и буду наблюдать, что он принимает и что отправляет Для этого не надо слушать всю сеть. Тем более, что это весьма сложно на коммутаторах.

Это как, интересно, ты сможешь подсунуть фальшивку, не зная алгоритма шифрования и не имея доступа к ключам, а также не зная - что в принципе и как передается серверу с клиента?

Мама, как много умных слов Алгоритм шифрования - что-то я очень сомневаюсь, что твой "разработчик" шифрует данные кодом атбаш И тем более настолько умен (хотя ты, думаю, в этом не сомневаешься), что изобрел свой гениальный метод криптования. Blowfish, DES, 3DES, IDEA - ты знаешь еще какие-нибудь обратимые алогритмы ширования симметричным ключом? Возможно, я что-то запамятовал.

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

Вот оно что. Нет, Novell ClientTrust мне совсем не интересен, я даже соглашусь, что он приемлем в плане безопасности. Обсуждаем сечайс вашу разработку. И ваш метод.

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

В свою очередь рекомендую более подробно пообщаться со своим "разработчником", чтобы ориентироваться в споре и представлять себе детали твоего проекта. Я понимаю, ты осуществляешь руководство им и ставишь задачи, но тогда как ты собираешься оспаривать то, чего не знаешь - четкого алгоритмы работы? Вывали на-гора хотя бы общий алгоритм, тогда и будем обсуждать его на предмет реальных недостатков, а не гадая на кофейной гуще, вот это действительно не назват грамотным. Или веди сюда своего... разработчика.
Далее, что и как. Что - например, имя пользователя. Как ты сказал выше, с помощью аналога КлиентТраста клиентская станция "представляется" хелперу (точнее, согласился с моими умозаключениями). Т.е., отправляет имя активного в данный момент пользователя. Как - возможно - покриптованно ключом любого симметричного алгоритма. Опять же, приходиться гадать - все зависит от того, что навоял твой программер.

Мы обходимся без крона и "простая логика" нам вполне доступна. Я вроде писал, что работа с потоком ведется в реальном времени. Наше решение пока далеко от идеала - но оно работает. И, думаю, заработает таки...

Либо ты все-таки об этом не писал, либо я умудрился эти твои слова пропустить, что маловероятно. Видимо, ты все же уточнил принцип работы у своего девелопера, перед тем как сейчас это написать, славно. Либо строго глянул спод бровей - "надеюсь все считается в реальном времени?" И под грозным взглядом твоему коллеге ничего не осталось, как заставить все считаться в реальном времени Как бы там ни было, теперь интересно было бы узнать, какой именно метод используется для направления потока на демон для обсчета, для дальнейшего обсуждения.

Я в курсе, каким правилами прописывается iptables Александр, потрудись говорить по делу, а не блистать знанием прописных истин.

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

Речь шла о том, что валится сетевая служба на клиентской стороне при разрыве соединения (пробовали и DROP, и REJECT) либо сервак пропускает трафик.

Смутно представляю, о какой именно службе ты говоришь. Если аналог клиенттраста - это вполне вероятно, если реджектить входящие на 3128.

Мне надо, чтобы прокси отвечал "403 Доступ запрещен"

Тогда такой вариант. Так важно, чтобы это показывал именно сквид? Поставь любой карликовый http-сервер, который будет отдавать страничку со словами "доступ запрещен" и какой-нить красивой картинкой, и настрой фаер, создав правило, чтобы все соединения на 3128 после превышения заданного лимита форвардились на этот http-сервер. Который и будет показывать вожделенную страницу "облома".

[Иван Левшин aka Ivan L.]

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

Я пока говорил всего-навсего об общей постановке вопроса - следовательно, разговоры о шифровании трафика и прочих прикладных особенностях. Следовательно, растекание мыслию по древу в этом направлении несколько преждевременно - не находишь. Вопрос звучал предельно конкретно - "как обрывать соединения средствами самого сквида?". Знаешь на него ответ и есть желание ответить - ради Бога. Нет - обсуждение iptables и бросание прочими страшными словами для меня интереса не представляет.

Что касаемо самого клиенттраста - помнится, тебе не удалось "сваять" что-либо более-менее приемлемое, после чего ты мне сообщил, что "это невозможно в принципе". Однако вот у Сергея Дуброва студент таки смог - причем зная Сергея, смею предположить, что решение получилось достаточно безопасным, чтобы его можно было использовать в промышленных условиях Сама мысль о запуске "аналога нашего клиенттраста" меня весьма позабавила - интересно, что именно ты собираешься "слушать"? И еще - каким образом? Сокеты тебе неизвестны - может, ты предположил, что мы по меньшей мере мультикасты шлем?

И еще - ты, наверное, удивишься, но в настоящее время мы достаточно успешно реализуем два проекта, о которых ты в свое время отозвался как о "принципиально невозможных".

Касаемо "обустройства mini-HTTP" - я не хочу делать никаких лишних телодвижений. Нужно, чтобы отвечал именно сквид - уже хотя бы потому, чтобы обработку логов для сбора статистики не приходилось вести по нескольким источникам.

2all - Идея с VPN понравилась, однако пока мы не нашли ответа на вопрос - каким именно образом организовать VPN между конкретными сокетами. Мне не надо шифровать весь трафик, это надо делать только с небольшой его частью. И еще - насколько я знаю VPN, организация VPN-соединения достаточно сильно грузит сервак. Учитывая, что на одной машины крутится OES.Linux с eDir и сопутствующими службами, VPN-сервер ставить как-то не хочется... Хотя - хелпер к сквиду проще, да и соединение отслеживать тоже проще, согласен.

[Иван Левшин aka Ivan L.]

Что касаемо разрыва соединения на порт прокси - мне не надо его рвать. Мне надо, чтобы прокси отвечал "403 Доступ запрещен" ТАк что не канает.

Лучше смотри в сторону PAM +Squid ....

Идея с pam обсуждалась в свое время еще на емке. Мне еще тогда не понравилась идея регулярной синхронизации учеток еДир и сквида. Не устраивает необходимость ввода дополнительных паролей при доступе в инет. Можно, конечно, заморачиваться с transparent proxy... Нужна именно прозрачная авторизация на сквиде без дублирования информация об учетках.

[Александр Читалкин]

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

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

Знаешь на него ответ и есть желание ответить - ради Бога.

Я тебе ответил. По поводу твоего каприза "без лишних телодвижений" - скажу твоими словами - вам шашечки, или кататься? Думаю все же кататься. Касаемо логов - их как вел, так и будет вести сквид, почему нет? Если клиент при активной учетке использует именно его? При блокировании учетки добавляем правило форварда на mini-http, при разблокировании - снимаем. В итоге, все поползновения клиентов успешно сливаются в логи, когда поползновения не возможны - ему сливается соответствующая надпись от http-сервера.

Сама мысль о запуске "аналога нашего клиенттраста" меня весьма позабавила - интересно, что именно ты собираешься "слушать"? И еще - каким образом? Сокеты тебе неизвестны - может, ты предположил, что мы по меньшей мере мультикасты шлем?

Е-мае... Ну неужто ТАК ТРУДНО запустить Iris и посмотреть как он работает? Зачем писать эту чушь? Можно перехватить ВЕСЬ трафик приходящий на машину и уходящий с нее, точно также, как это делает твой демон на линуксе.

Что касаемо самого клиенттраста - помнится, тебе не удалось "сваять" что-либо более-менее приемлемое, после чего ты мне сообщил, что "это невозможно в принципе". Однако вот у Сергея Дуброва студент таки смог - причем зная Сергея, смею предположить, что решение получилось достаточно безопасным, чтобы его можно было использовать в промышленных условиях

Я его сваял, и ты его видел. Резолюция моя была такова - это работает, но это не безопасно. Если хотим получить большего - это надо ваять гораздо больше и серьезнее. Еще раз повторяю, что я не программер - и писать софт не мой конек. Ты мне это твердил сам, что я, как и ты - не программеры. Разумеется, посидев перед экраном плотненько пару недель, задачу решить бы удалось и мне, при всем моем скудном опыте программиста. Однако делать это у меня не было никакого желания. А студенты - я полностью с тобой согласен в плане их большого потенциала - они могут делать многе на голом энтузиазме, ничего не ожидая в замен, кроме новой интересной работы, дающего бесспорный левел-ап. Что касаемо меня - частично возрастом, частично твоими заслугами этот энтузиазм сошел на нет.

И еще - ты, наверное, удивишься, но в настоящее время мы достаточно успешно реализуем два проекта, о которых ты в свое время отозвался как о "принципиально невозможных".

Каких же? Ума не приложу, когда я мог заикаться о чем-то "невозможном". Не в моих правилах. Очень трудно, труднозатратно - да. Но не невозможно.

Мне не надо шифровать весь трафик, это надо делать только с небольшой его частью.

IPSEC. Создаешь политику на локальной машине с соответствующим правилом. Шифруется только трафик на нужный порт и на нужный хост. Соответственно, данный хост должен поддерживать ipsec туннели.

И еще - насколько я знаю VPN, организация VPN-соединения достаточно сильно грузит сервак. Учитывая, что на одной машины крутится OES.Linux с eDir и сопутствующими службами, VPN-сервер ставить как-то не хочется...

GUI потребляет ресурсов не меньше, а ресурсов конкретно ОЗУ - больше. VPN, естетсвенно, сильно нагружеает процессор, но на двухпроцессорной машине с этим проблем возникнуть не должно.

[Иван Левшин aka Ivan L.]

Александр Читалкин - no comments. Можешь продолжать далее заниматься надуванием щек Касаемо конкретно клиента и Iris - во-первых, ты просто не сможешь его запустить (прав не хватит на доступ к файлу). Во-вторых - у тебя не будет прав на установку Iris. Ежели все же сможешь найти кого-то с соответствующим количеством привилегий - ради Бога, пытайся. Если засечем - у товарища резко прав уменьшится, ибо подобные деяния мы никак кроме как попытку взлома квалифицировать не будем.
Касаемо того, что ты говорил и чего ты не говорил - давай будем считать, что ты ничего не говорил На протяжении полутора лет Все это время у меня были слуховые галлюцинации. Теперь еще и зрительные - разгребаем после тебя настройки Но всего этого на самом деле нет, не было и быть не может - у нас групповое помешательство.