LINUX.ORG.RU
ФорумAdmin

firewall - клиент и авторизация


0

0

Привет всезнающий АЛЛ!

Есть сеть, компов 60 под виндой (домен Вин2к3). Их надо пускать в сеть, сейчас все крутится под вендой и траффик-инспектором, но изза кучи глюков от этой ерундени решили отказаться, и перевести все это дело под линух. Поднять сквид и повесить считалку траффика не проблемма, проблемма в том что пускать нужно пользователей по логинам-паролям, а работать у них должны после авторизации все сервисы, а не только www. Авторизация в сквиде не подходит для этого, нужен какойто файрвол-клиент. Авторизация в домене неподходит - половина юзеров сидят под одним логином, пересаживаясь с компа на комп. Кто что может посоветовать для авторизации?

anonymous

Re: firewall - клиент и авторизация

netware

svyat ()

Re: firewall - клиент и авторизация

Не буду навязывать и рекламировать, но рекомендую ознакомиться с дистрибутивом ClarkConnect. Все сетевые сервисы интергированны для единой авторизации пользователей, не связанной с доменом Windows.

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

VPF ()

Re: firewall - клиент и авторизация

Ну тут только один вариант VPN. Копай в сторону pptp или pppoe.

I3rain ()

Re: firewall - клиент и авторизация

Угу, связка radius+mysql+pppd+pptpd+squid Юзерам в соответствии с их группой в Radius'е выдается динамический IP-шник из 3-х пулов в подсети 10.0.0.0/8 соответственно ты можешь рулить правами через iptables/squid what ever else основываясь на принадлежности IP к тому или иному пулу. Проблема в том что в случае динамических IP усложняется анализ логов squid - нужно сверятся с данными radwtmp/radacct.

НО все это пионерская поделка - яркий пример забивания гвоздей микроскопом.

А вот так должно быть: Аутентификация по паре IP-MAC, IDSка следит за появлением в сети левых пар и жутко ругается. В этом ей помогает DHCP option 82 (читай нормальный свитч). Если ниасилил связку Squid/NTLM аутентификация ставь ISA - все равно корпоративная слицензия с SoftwareAssurance у любой конторы больше 5 ПК must be.

Юзеров которые садятся работать за чужие компы сношать без вазелина в такой последовательности: сначала руководители и безопасник, потом безопасник в своей каморке, затем админ в своей каморке.

Если вдруг нужен прямой доступ к опр сервисам типа VPN - то разрешать для определенных пар MAC/IP. Что должна делать IDSка и так понятно. Есть решение типа SOCKS - 80% типов приложений за глаза.

VPN - для сетей где админ не контроллирует ситуацию (как раз у меня) АD должна быть поднята в сетях начиная с 2-х машин. DMZ и свой собственный почтовый и веб сервер должен быть у любой уважающей себя конторы.

Macil ★★★★★ ()
Ответ на: Re: firewall - клиент и авторизация от Macil

Re: firewall - клиент и авторизация

>Угу, связка radius+mysql+pppd+pptpd+squid Юзерам в соответствии с их группой в Radius'е выдается динамический IP-шник из 3-х пулов в подсети 10.0.0.0/8 соответственно ты можешь рулить правами через iptables/squid what ever else основываясь на принадлежности IP к тому или иному пулу.

squid, в принципе из этой связки можно и выкинуть. А при желании и SQL, но с ним удобнее (и лучше postgresql). Кстати, можно выкинуть и RADIUS. В случае клиентов в одном сегменте сети вместо pptp лучше использовать pppoe.

>Проблема в том что в случае динамических IP усложняется анализ логов squid - нужно сверятся с данными radwtmp/radacct.

Чушь, squid может записывать в логи имена аутентифицированных пользователей.

>А вот так должно быть: Аутентификация по паре IP-MAC, IDSка следит за появлением в сети левых пар и жутко ругается. В этом ей помогает DHCP option 82 (читай нормальный свитч).

А вот тут-то и начинаются проблемы. :) Например такие как:

>Юзеров которые садятся работать за чужие компы сношать без вазелина в такой последовательности: сначала руководители и безопасник, потом безопасник в своей каморке, затем админ в своей каморке.

>Если вдруг нужен прямой доступ к опр сервисам типа VPN - то разрешать для определенных пар MAC/IP. Что должна делать IDSка и так понятно. Есть решение типа SOCKS - 80% типов приложений за глаза.

qwe ★★★ ()
Ответ на: Re: firewall - клиент и авторизация от qwe

Re: firewall - клиент и авторизация

>Чушь, squid может записывать в логи имена аутентифицированных пользователей.

Проблема в том, что squid не может авторизировать на основании RADIUS. (или я очень ошибаюсь??? )А HttpAuth - взывает много проблем с некоторыми сайтами и программами

>А вот тут-то и начинаются проблемы. :) Например такие как:

1. У PPTP можно сохранять пароль на клиенте. Ничто не мешает пользователю сесть за компьютер, где подключение уже установлено, подсмотреть пароль и т.п. Такие вещи решаются искл. с помощью орг. мер. А что не говори, AD предоставляет больше возможностей по недопущению подобных вещей.

2. Проблема очень серьезная и не решается в "общем" случае.

>squid, в принципе из этой связки можно и выкинуть.

Лучше не выкидывать. Увы, но в современных корпоративных условиях выход в инет только через прокси.

И да, конечно же не забывать поднимать DNS, даже если используется прокси. Не далее чем в пятницу напоролся на подобную вещь...

Macil ★★★★★ ()
Ответ на: Re: firewall - клиент и авторизация от Macil

Re: firewall - клиент и авторизация

>Проблема в том, что squid не может авторизировать на основании RADIUS. (или я очень ошибаюсь??? )А HttpAuth - взывает много проблем с некоторыми сайтами и программами

А зачем аутентифицированного пользователя ещё раз авторизовать на squid`e, если Вас интересует всего лишь его имя в логе, да и авторизовать в общем-то тоже можно.

>1. У PPTP можно сохранять пароль на клиенте. Ничто не мешает пользователю сесть за компьютер, где подключение уже установлено, подсмотреть пароль и т.п. Такие вещи решаются искл. с помощью орг. мер. А что не говори, AD предоставляет больше возможностей по недопущению подобных вещей.

Если клиент уже аутентифицирован AD, зачем делать это ещё раз в pptp? Я и говорю о том, что клиент должен отвечать за сохранность своего аккаунта, а не за IP или MAC адрес.

>2. Проблема очень серьезная и не решается в "общем" случае.

Решается всё. Только одни находят нормальное решение, а другие костыли.

>Увы, но в современных корпоративных условиях выход в инет только через прокси.

Только из за возможности кеширования.

qwe ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.