Другу задачу, пов'язану з отриманням дозволу на звернення до ресурсного сервера, вирішує інша частина Kerberos-сервера – сервер квитанцій (Ticket-Granting Server, TGS). Сервер квитанцій для легальних клієнтів виконує додаткову перевірку і дає клієнтові дозвіл на доступ до потрібного йому ресурсному серверу, для чого наділяє його електронною формою-квитанцією. Для виконання своїх функцій сервер квитанцій використовує копії секретних ключів всіх ресурсних серверів, які зберігаються у нього в базі даних. Окрім цих ключів сервер TGS має ще один секретний DES-ключ, який розділяє з сервером AS.
Третє завдання – отримання дозволу на доступ безпосередньо до ресурсу – вирішується на рівні ресурсного сервера.
Вивчаючи досить складний механізм системи Kerberos, не можна не задатися питанням: який вплив роблять всі ці численні процедури шифрування і обміну ключами на продуктивність мережі, яку частину ресурсів мережі вони споживають і як це позначається на її пропускній спроможності?
Відповідь вельми оптимістична – якщо система Kerberos реалізована і конфігурована правильно, вона трохи зменшує продуктивність мережі. Оскільки квитанції використовуються багато разів, мережеві ресурси, що витрачаються на запити надання квитанцій, невеликі. Хоча передача квитанції при аутентифікації логічного входу декілька знижує пропускну спроможність, такий обмін повинен здійснюватися і при використанні будь-яких інших систем і методів аутентифікації. Додаткові ж витрати незначні. Досвід впровадження системи Kerberos показав, що час відгуку при встановленій системі Kerberos істотно не відрізняється від часу відгуку без неї – навіть в дуже великих мережах з десятками тисяч вузлів. Така ефективність робить систему Kerberos вельми перспективною.
Серед вразливих місць системи Kerberos можна назвати централізоване зберігання всіх секретних ключів системи. Успішна атака на Kerberos-сервер, в якому зосереджена вся інформація, критична для системи безпеки, приводить до краху інформаційного захисту всієї мережі. Альтернативним рішенням могла б бути система, побудована на використанні алгоритмів шифрування з парними ключами, для яких характерний розподілене зберігання секретних ключів.
Ще однією слабкістю системи Kerberos є те, що початкові коди тих застосувань, доступ до яких здійснюється через Kerberos, мають бути відповідним чином модифіковані. Така модифікація називається «керберизацией» додатку. Деякі постачальники продають «керберизированные» версії своїх застосувань. Але якщо немає такої версії і немає початкового тексту, то Kerberos не може забезпечити доступ до такого застосування.
4.2 Настройка мережевих служб для здійснення авторизації доступу до мережі Інтернет
Класичним вирішенням стандарта підприємства для організації Інтернет-сервісів є сервер під управлінням UNIX. Практично завжди для Web і FTP трафіку використовують кеширующий сервер SQUID, який також є стандартом de facto.
Стандартним способом надання доступу до SQUID-серверу є доступ на основі специалицированных списків доступу (Access Lists або ACL). У свою чергу списки доступу зазвичай будуються на основі IP-сетей, яким дозволений доступ до SQUID. Наприклад, визначимо ACL, яка описує мережу 10.128.0.0/16 (або з маскою 255.255.0.0). і ACL, яка описує взагалі все адресаsquid.conf:
acl net10128 src 10.128.0.0/16
acl all src 0.0.0.0/0
а зараз дозволимо їй доступ до Інтернет ресурсам
http_access allow net10128
а всім останнім - заборонимо:
http_access deny all
Після цього, тільки комп'ютерам із заданої мережі дозволений доступ до Інтернет. При використанні Internet-ресурсов, в балку-файл squid записується інформація про конкретну адресу, що запитала конкретний Інтернет-ресурс: acess.log:
1032862411.262 96 10.128.15.4 TCP_MEM_HIT/200 2581 GET
http://www.ru/eng/images/ssilki.jpg board/sag NONE/- image/jpeg
Тут присутсвует дата, розмір ресурсу, IP-адрес станції, зпросившей ресурс, і сам ресурс. З такого роду записів можна підрахувати трафік як по станції, так і по підмережі.
Проте приведена вище технологія дозволяє контролювати трафік по IP-адресу Інтернет-користувача. В більшості випадків цей спосіб цілком підходить, проте при цьому необхідно, щоб за конретним комп'ютером завжди працювала конкретна людина.
Ця умова виконується не завжди і тоді облік трафіку порушується. Ось типові умови, при яких потрібна інша схема авторизації в Інтернеті:
Різні користувачі працюють на одному і тому ж робочому місці (наприклад, позмінно).
Користувачі взагалі не прив'язані до конкретних комп'ютерів.
Користувачі працюють в термінальних сесіях термінального сервера. Тоді взагалі весь Інтернет-трафік йде з IP-адреса сервера.
Тому часто встає проблема обліку трафіку не на основі IP, а на основі іншої інформації.
4.2.1 Авторизація на основі логіна і пароля
Логічним вирішенням проблеми авторизація на основі логіна і пароля є авторизація в SQUID по логіну і раолю. Така можливість в SQUID, естесвенно передбачена. У SQUID для цього розроблена можливість авторизувати через зовнішню програму, яка просто "говорить" "та чи ні" на визначеного користувача і пароль. Т.ч. Можна проводити авторизацію по обліковому запису уміє проводити авторизацію через облікові записи UNIX, через текстові файли і тому подібне
Наприклад, для того, щоб користувач авторизувався через файл /usr/local/squid/passwd формату Веб-сервера-авторизації (формат Apache), потрібно скомпілювати squid разом з цим модулем (--enable-auth="ncsa; докладніше за див. документацію до SQUID). І в конфиг SQUID додати ACL вирішуюче правило:
Дозволити доступ користувачам dima petya vasya, паролі яких будуть перевірені через файл /usr/local/squid/passwd
acl MYUSERS proxy_auth dima petya vasya
http_access allow MYUSERS
http_access deny all
authenticate_program /usr/local/squid/bin/ncsa_auth /usr/local/squid/etc/passwd *
(*для версии 2.4).
При цьому, це вирішує поставлені в "Введенні" проблеми, проте додає деякі незручності користувачам і адміністраторові:
При первинному вході в Інтернет користувачеві потрібно набратьв броузере логін\пароль для доступу до SQUID. І кожному користувачеві необхідно пам'ятати свої параметри.
Адміністраторові необхідно вести базу логінів і паролів у файлі.
4.2.2 Авторизація через облікові записи Windows
При роботі в Windows-мережах кожен користувач при вході в мережу проходить авторизацію в NT(2000) -домене. Було б здорове використовувати ці дані для авторизації SQUID. Тоді вирішуються проблеми ведення в SQUID окремої бази даних користувачів і, як виявилось, можна вирішити проблему запиту логіна\пароля в броузере при вході в Інтернет.
Головна проблема при вирішенні авторизації через Windows-домен - знайти і набудувати програму для авторизації заданого користувача в Windows-домене. Команда SQUID рекомендує користуватися програмою winbindd, яка є частиною проекту SAMBA (реалізація Windows сервера і клієнта під UNIX), SQUID, починаючи з версії 2.5 підтримує різні схеми авторизації по логіну\паролю, включаючи basic і NTLM (NT Lan Manager). Basic-схема призначена для авторизації через введення логіна\пароля в броузере, а NTLM-схема призначена для автоматичного прийому броузером логіна, пароля і домена, під якими користувач реєструвався в Windows-домене. Т.ч. за допомогою NTLM-авторизации можна автоматично реєструватися в SQUID без ручного підтвердження логіна і пароля.
4.3.3 Практичне вирішення побудови системи авторизації через Windows домен
Практичне вирішення проблеми було знайдене досвідченим шляхом і може бути не найвитонченішим і правильнішим. Але краса його в тому, що воно дороблене та кінця і працює.
Початкові дані:
1. Комп'ютер, підключений до Інтернет зі встановленою ОС: FREEBSD 4.4 (версія і сама ОС не мають принципового значення).
2. Мережа, що містить близько 200 Windows-станций, включаючи термінальні сервери і клієнти.
3. Близько 250 аккаунтов в домені під управлінням Windows 2000 Advanced сервер (домен WORK і 4 довірителях домена).
Завдання:
Забезпечити авторизацію користувачів на SQUID через облікові записи Windows найбільш зручним способом.
План дій:
1.Установка і конфігурація SAMBA.
Отже перше, що треба зробити - встановити SAMBA для того, щоб уміти авторизуватися в Windows-домене. Я встановив версію 2.2.6pre2. Причому, важливо скомпілювати SAMBA з підтримкою winbind, тобто з параметрами:
-with-winbind
-with-winbind-auth-challenge
Примітка:
У FREEBSD SAMBA була зібрана з портів (ports) і виявилось, що з поточною версією не збирається бібліотека CUPS. Тому SAMBA була зібрана без неї (--without_cups).
Після установки, SAMBA потрібно набудувати на домен Windows мережі і на використання winbind:
[global]
workgroup = WORK - Ім'я нашого Windows-домена
netbios name = vGATE - Ім'я сервера (необов'язково)
server string = vGate
hosts allow = 10.128. 127. - Для безпеки.
winbind separator = +
winbind use default domain = yes
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
template homedir = /home/winnt/%D/%U
template shell = /bin/bash
max log size = 50
security = domain
password server = Primary Exch - сервери паролів (PDC, BDC)
encrypt passwords = yes
Слід звернути увагу на 2 речі:
1. Спочатку в параметрі password server був вказаний тільки PDC (Primary) і winbind не зміг знайти контроллер домена. Все запрацювало коли був доданий BDC (Exch).
2. Обидва імена - це NETBIOS імена і для того, щоб вони равильно інтерпретувалися в IP я прописав їх в /usr/local/etc/lmhosts
10.128.1.40 Primary
10.128.1.34 Exch
Після цього необхідне заригестрировать SAMBA в домені Windows. Для цього нужэно набрати команду:
/usr/local/sbin/smbpass -j WORK (наш домен) -r Primary(наш PDC) -UAdministrator
Після цього, слід ввести пароль адміністратора домена.
Спостерігалися проблеми з samba 2.2.4 і реєстрацією в нашому домене - саме тому була поставлена версія 2.2.6 з портів.
Далі можна запустити nmbd (/usr/local/sbin/nmbd -D) краще з включеним дебагом (-d9) і подивитися в балку-файл, що мережа нормально видно.
Далі можна сміливо пускати winbindd (/usr/local/sbin/winbindd -d9) - теж з дебагом і подивитися як він себе "відчуває" в нашій мережі. Опісля зразково секунд 10, можна перевірити а чи запустився winbind і чи функціонує він.
Для взаємодії з winbind служить команда wbinfo. Перевірити чи "бачить" вона winbindd взагалі можна командою wbinfio -p. Якщо вона відповість: 'ping' to winbindd succeeded, то означає все гаразд. Інакше треба дивитися в балку-файл winbindd і розуміти чому він не запустився. (Насправді запускається він завжди, та ось на запити відповідає тільки якщо правильно бачить мережа). Далі можна спробувати перевірити а чи бачить winbindd сервер з паролями користувачів (wbinfo -t). Сервер повинен сказати "Secret is good". І, нарешті, можна спробувати авторизуватися з UNIX в Wondows домен: