SQUID и аутентификация по eDir (Мысль вслух)

[Музалёв Николай]

2 Щипунова Татьяна
От себя добавлю, что

1. не должно быть пользователей с одинаковыми именами, хотя бы и в разных контекстах

сводит на "нет" прелесть механизма контейнеров и (в некоторых организациях) может серьезно нарушить механизм нотации пользователей. Именно так и произошло в моём случае. Пришлось делать приерно следующее:
1. задействовать поле Given Name (спорю - ни у кого оно не заполнено....)
2. в указанном поле прописать привычный нашим пользователям логин. У нас принята и жестко поддерживается логин в виде ИМЯ.КОНТЕЙНЕР (контейнер - по сокращению подразделения). В соответствии с нашими стандартами на всё уходит 7-8 литер. Пользователи привыкли и теперь даже не мыслят другого вида логина - в этом для них информация не только "кто", но и "где".
3. в свойствах объекта LDAP Group , в закладке Attribute Map пришлось перемапить uid на Given Name (что добавляет ровно 10 секунд доп. работы при создании нового пользователя - надо это поле заполнять)

2 PavelKHTW

.... под одним .... ходить несколько пользователей?

Борьбу ведем административно, авторитарно и очень недемократично: пароли надо хранить в секрете. Все наши о том землю ели (Документ, п. 15) и на этом основании им твердо обещано, что если Интернет-инцидент произойдет из-за утраты контроля над паролем, то виновному отшибут гениталии.

[Щипунова Татьяна]

А как ведете борьбу с тем что под одним логином паролем могут ходить несколько пользователей?

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

[Сергей Дубров]

2 Щипунова Татьяна
От себя добавлю, что

1. не должно быть пользователей с одинаковыми именами, хотя бы и в разных контекстах

сводит на "нет" прелесть механизма контейнеров и (в некоторых организациях) может серьезно нарушить механизм нотации пользователей.

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

1. задействовать поле Given Name (спорю - ни у кого оно не заполнено....)

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

[Константин Ошмян]

У нас очень строго с передачей своего пароля соседу, премии за это могут лишить

Тем не менее, при аутентификации клиента (т.е. браузера) с прокси-сервером (Squid) используется схема Basic, при которой имена вместе с паролями пересылаются по сети в нешифрованном виде. Более того, они передаются фактически в каждом запросе, так что (при условии, что сеть не на свитчах) подснифферить чей-либо пароль - только вопрос времени. А с учётом того, что это тот же самый пароль, что используется для доступа к сети - сами понимаете... Поэтому у себя мы вынуждены были от такой конфигурации отказаться. Используем сейчас аналогичную, но завязанную не на NDS, а на Active Directory - тогда есть возможность при аутентификации использовать схему NTLM, при которой пароли по сети не пересылаются вообще.

[Музалёв Николай]

2 Константин Ошмян
Коллега! при всем уважении, не могу считать серьезным ваше заявление:

при условии, что сеть не на свитчах

Мне трудно представить современную (2000 и позднее) сеть НЕ НА свичах. Ноне пристойный управляемый коммутатор стоит ДЕШЕВЛЕ навороченного хаба, ибо время их ушло и искать надо "под заказ"...

Да и вообще - ИМНО - про перехват паролей...
В конторе, где есть что и зачем перехватить, а пользователи такому обучены, без сомнения найдут деньги на коммутаторы во-первых и на доп. средства безопасности во-вторых, (и на первый отдел, в-третьих)иначе получается профанация....
А в тривиальной госконторе типа рогов&копыт на 1н перехваченный (кем-то, когда-то, как-то по случаю... и главноее - зачем?) пароль придется немерянно случаев, когда тетенька Маня тихим незлым голосом поведала его "по-секрету-всему-свету": "Девочки, я в командировку... если завтра придет имярек из госснаба, то посадите его за мой компунтер и НАБЕРИТЕ ЕМУ МОЙ ПАРОЛЬ, вот такие буковки.... вот тут, на бумажке...." Вы с таким не сталкивались??
Поэтому этот ваш тезис кажется мне сомнительным.

2 Щипунова Татьяна
Другое дело , что изложенный госпожой Татьяной метод имеет ДЕЙСТВИТЕЛЬНО серьезную ОРГАНИЗАЦИОННУЮ дыру, а именно - возможность запомнить пароль в диалоговом окне, что позволяет работать "под соседа" даже и не зная его пароля.
Вот тут ничего придумать пока не могу... Кстати, а у вас как с этой проблемой? Наверное, я просто просмотрел ее решение.

[Константин Ошмян]

Да и вообще - ИМНО - про перехват паролей...
В конторе, где есть что и зачем перехватить, а пользователи такому обучены, без сомнения найдут деньги на коммутаторы во-первых и на доп. средства безопасности во-вторых, (и на первый отдел, в-третьих)иначе получается профанация....

Не согласен, причём категорически.

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

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

В-третьих, при Basic-аутентификации пара имя/пароль передаётся, как я писал, от браузера к прокси-серверу. Соответственно, защищать от прослушивания надо весь этот путь. У нас, например, сеть большая и "разлапистая", при этом вся на свитчах. Однако, прокси-сервер, через который происходит выход в Интернет, находится в одном месте, а пользователи - в дюжине разных, территориально разбросанных по нескольким площадкам. И запросы к прокси-серверу зачастую проходят не через один-единственный свитч, а через множество связного оборудования разных видов - свитчи, роутеры, конверторы интерфейса, линии связи, в конце концов. Так что я для себя пришёл к однозначному выводу - лучше по сети нешифрованный пароль не передавать.

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

[skoltogyan]

1. Пользователь с рабочего места пожет получать, например:
- через прокси выход для броузера
- доступ к ньюс-серверам
- ssh куда за приделы фирмы
- прямой выход за приделы фирмы для работы некоторых приложений
- icq.
- звонить на фирму по модему, что-бы получать выход в инет
....

2. Предприятие будет интерисовать и А СКОЛЬКО БАЙТ SEND/RECEIVE каждый, кто имеет доступ к сервисам интернет стягивает (кроме обычного - а куда через прокси ходил)

3. Предприятие будет интерисовать что-бы доступ к конкретным сервисам (пункт 1) получал не IP (который можно назанчить себе, когда станция соседа отключена), а ЧЕЛОВЕК

Для этог можно поднять:
VPN+Radius
С любой станции: W98...XP, Linux подымается VPN соединение (аднные и пароль пойдут в шифрованом виде) между станцией и сервером VPN
При подьеме именно этот ЛОГИН (vpn-ий) получит именно свой IP (это все из РАДИУСА ВОЗМЕТСЯ).

Далее уже можно строить правила в прокси, фаерволе для предоставления нужного доступа этому IP (человеку)
Radius будет вести статистику IN/OUT байт...

Как я вижу по моему окружению- ВАЖНЕЕ иметь именно такой доступ, чем только доступ к БРОУЗЕРУ..

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

skoltogyan

Вот поэтому мне и интересен RADIUS .. могу еще добавить - наличие в конторе беспроводного доступа тоже вписывается сюда, и вроде бы даже неплохо так. А угроза взлома wireless куда более реальна, увы, чем гипотетический спуфинг свичей предприятия. Вот только, насколько я понимаю, новелловский RADIUS не работает с 802.11х пока что.

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

[skoltogyan]

FreeRadius ( on linux, freebsd) может хранить списсок пользователей, паролей, IP для них, огрнаичения в
1. файле
2. mysql
и еще-чем-то..

Статистику по использованию выдает в виде обычного файла, где пишет кто, когда начал, сколько туда и назад, когда закончил работу...

Гуру от Линукса сказал, что можно настроить так, что за паролем будет лезь по LDAP, куда направишь. Но это у меня на сегодня не получилось.
А в остальном работает.


Как себя ведет тот Радиус, что с BM (ведет-ли он какие логи и как про обьемы - неведаю : ( )