авторизація у squid

[Volodymyrko]

Добрий день ...
в мене таке питання:
зараз на сквіді використовую авторизацію за допомогою ncsa_auth ,  але за домогою сніфера можна без проблем взнати будь-який пароль ...
Чи можна якось запобігти цьому, чи вміє скдів шифрувати паролі, чи є якась шифрована авторизація в ньому  (пошук поки-що нідочого не привів)

[PAL]

Справа не в сквіді - справа в бровзері, що авторизується згідно специфікацій HTTP

А що за завдання взагалі? Як я розумію, мережа недовірена (щось на зразок "домашньої мережі")? Можливо, краще використовувати інші механізми (програми) авторизаціі?

[Volodymyrko]

А що за завдання взагалі? Як я розумію, мережа недовірена (щось на зразок "домашньої мережі")? Можливо, краще використовувати інші механізми (програми) авторизаціі?

Завдання стандартне: с-ка по корситувачах по трафіку..  та і можливість доступу в інтернет з бідь-якого компюрета зі своїми "правами" ..
Це мережа на роботі, тому думаю використовувати pptp  чи pрpoe не доцільно . а інших механізмів навіть не знаю ...
та і контролювати потрібно зрубшого тільки http i ftp-трафік ... свіда тут  думаю хватає.

сьогодні вичитав про digest-авторизацію, ніби підходить: пароль шифрований, тільки треба щоб браузер підтримував, але думаю що всі сучасні браузери підтримують,( трохи погано що на сервері паролі мають бути відкриті ...  хоча це вже набагато краще ніж в мережі відкриті ..)  
Яка ваша думка ?

[Volodymyrko]

Можливо, краще використовувати інші механізми (програми) авторизаціі?  

1.Про які саме механізми  чи програми ви говорите, наведіть приклад ....  ??

2. То що виходить що за домогою squid-а  нічого зробити не можна . ?

[aleks_ss]

Можливо, краще використовувати інші механізми (програми) авторизаціі?  

1.Про які саме механізми  чи програми ви говорите, наведіть приклад ....  ??

2. То що виходить що за домогою squid-а  нічого зробити не можна . ?

Можете спробувати розглянути варіант авторизації через самбу в домені, наприклад я використовував таку систему. Далі ставите squidguard, яким зарізаєте "зайвий"трафік, а sarg'ом вимірюєте власне обсяги скачаного. На Windows налаштуйте відклик на identd, який запустіть на сервері і все буде працювати :-)

[PAL]

Можливо, краще використовувати інші механізми (програми) авторизаціі?  

1.Про які саме механізми  чи програми ви говорите, наведіть приклад ....  ??

Я мав на увазі щось на зразок pptp або stargazer.
Але, як я бачу, для Вас це не дуже підходить...

Наведіть порядок у мережі - за сніфер та викрадання паролів взагалі-то треба користувачам добряче по голові стукати. Адміністративними методами. Бо безпеку лише технічно взагалі неможливо нормально забезпечити.

А щодо digest - треба перевіряти, але щось мені здається, що IE такого не вміє
Можна ще поритися у напрямку kerberos

2. То що виходить що за домогою squid-а  нічого зробити не можна . ?

Сквід взагалі-то кешуючий проксі, а не система безпечної авторизаціі користувачів

[Volodymyrko]

Я мав на увазі щось на зразок pptp

так, це ж не роздача інтернету за гроші чорт зна кому,  все має бути досить просто, тут і так не всі вміють навіть проксі прописати ..... буде затяжко ....

а сніфер та викрадання паролів взагалі-то треба користувачам добряче по голові стукати

так, але як знайти, хо вкрав, і хто запускає сніфер, адміністратор я тут не один, я тільки за нет відповідаю, кожен в себе на компютері має адміністративний пароль  і робить що хоче ... IP, компи мінються регулярно, я розумію що так не має бути, але нічого зробити не можу, тому шукаю вихід на стороні сервера,squid-a і т.д.

А щодо digest - треба перевіряти, але щось мені здається, що IE такого не вміє

перевіряв -  вміє, авторизує і працює, і Опера вміє,
а от qip,icq - не вміють, але зараз саме через сквід ходять, треба хіба їх на socks переводити ,,,
А на скільки digest безпечний

[PAL]

А щодо digest - треба перевіряти, але щось мені здається, що IE такого не вміє

перевіряв -  вміє, авторизує і працює, і Опера вміє,
а от qip,icq - не вміють, але зараз саме через сквід ходять, треба хіба їх на socks переводити ,,,

Ну, не обов'язково. Можна, наприклад, взагалі NAT використати.

А на скільки digest безпечний

НМД досить безпечний. Десь так на рівні md5

[RomadinR]

А на скільки digest безпечний

Дайджест безпечний у тому смислі, що навіть перехопивши md5-суму авторизації зловмиснику ще треба повозитися, щоб отримати пароль, хоч, в принципі, це і можливо.
Якщо розглядати його з точки зору гарантованої авторизації - то він не є таким уже надійним, бо перехопивши md5-суму, все таки можна, використовуючи спеціально написане ПЗ, отримати доступ до Інтернету через Squid. Оскільки, скоріше за все, використовується незмінний realm сервера, то і "правильна" md5-сума не зміниться, поки користувач не змінить пароля.

В університетській мережі використовуємо і digest, і basic. Інші методи не використовуються, оскільки немає загальноуніверситетського Samba-домена чи LDAP-сервера. Користувачі попереджені про небезпеку. В realm відповідно вписано тип авторизації. Перехоплення по basic були. По digest поки що не зафіксовано. Можливо через те, що у мережах гуртожитків використовується прив'язка ір-адреси до МАС-адреси і порта комутатора, а на проксі сервері детальний лог пишеться у базу і доступний користувачу, тобто користувач дуже просто може "вичислити" (за сприяння адміністраторів) "хто юзав мій нет і весь його виюзав" (С)

[Volodymyrko]

оскільки немає загальноуніверситетського Samba-домена чи LDAP-сервера

1.Samba ніби вміє шифрувати , але чи  надійніше від digest-у  ?
2.LDAP- він хіба шифрує

В realm відповідно вписано тип авторизації

про який саме "тип авторизації" йде мова ..  ,  або які вони бувають

[PAL]

2.LDAP- він хіба шифрує

1) вміє ssl
2) вміє md5, sha та ще дещо у полях паролів.

[RomadinR]

В realm відповідно вписано тип авторизації

про який саме "тип авторизації" йде мова ..  ,  або які вони бувають

Ось приблизно так:

Код: [Вибрати]

auth_param digest program /usr/local/bin/my_auth_digest.pl
auth_param digest children 10
auth_param digest realm CNU Squid Proxy Cache (digest)
auth_param digest nonce_garbage_interval 25 minutes
auth_param digest nonce_max_duration 120 minutes
auth_param digest nonce_max_count 25000
auth_param digest nonce_strictness off
auth_param basic program /usr/local/bin/my_auth.pl
auth_param basic children 5
auth_param basic realm CNU Squid Proxy Cache (basic)
auth_param basic credentialsttl 2 hours
Використовуються 2 типи - Digest і Basic. Спочатку запитується Digest, а якщо не пройшов, то Basic.
Так, я розумію, що це таки не зовсім вірно з точки зору безпеки, але, на жаль, є багато потрібних програм, які не вміють Digest :-(

[Volodymyrko]

2.LDAP- він хіба шифрує
1) вміє ssl
2) вміє md5, sha та ще дещо у полях паролів.

тут мається на увазі шо він шифрує коли :
authenticate_program /usr/...../squid_ldap_auth  ? тобто у звязці зі squid-ом,(  якщо так , то якщо можна трохи детільніше )

/usr/local/bin/my_auth_digest.pl
і
/usr/local/bin/my_auth.pl

це якісь сцеціалні програмки мають бути чи підйдуть штатні digest_pw_auth  і
/usr/sbin/ncsa_auth  
і як воно працює, а саме як питає паролі: перший раз питає той  безпечний а потім небезпечний, чи певну кількість раз один а потім певну кількість раз інший ....
такий подвійний тип авторизації підтримують всі версії , чи може якімь новіші

[RomadinR]

/usr/local/bin/my_auth_digest.pl
і
/usr/local/bin/my_auth.pl

це якісь сцеціалні програмки мають бути чи підйдуть штатні digest_pw_auth  і
/usr/sbin/ncsa_auth  
і як воно працює, а саме як питає паролі: перший раз питає той  безпечний а потім небезпечний, чи певну кількість раз один а потім певну кількість раз інший ....
такий подвійний тип авторизації підтримують всі версії , чи може якімь новіші

Це самописні сценарії на перлі. У нашому випадку, ті, що йдуть разом із squid не підійшли, бо хотілося зберігати логіни-паролі у базі даних і враховувати ліміти, от і довелося писати своє.
Штатні, думаю, підійдуть, але (принаймні у версіях десь до 2.5 точно) у ncsa_auth була виявлена така проблема: ncsa_auth бере лише перші 8 символів пароля для перевірки. htpasswd, правда, веде себе так само, тобто, пароль проходить, але проходить і будь-який пароль, у якого перші 8 символів такі ж. Проблема точно у системному crypt, який використовують обидві програми. Крім того, якщо використовувати таку ж схему, як у нас, то доведеться якось синхронізувати файлики для ncsa_auth і digest_pw_auth.
Питає спочатку digest, потім basic.
Така схема у нас працює ще десь із перших стабільних 2.5.

[Volodymyrko]

Це самописні сценарії на перлі

Можете детільніше пояснити роботу цих сценаріїв, може якийсь наприклад.  
які дані вони отримують на вході ,  в якому вигляді зберігаються  в базі,  в одному і другому випадках