Розгортання керуючого proxy-сервера для підприємства програмними засобами Squid

Размещено на http://www.allbest.ru/

ДЕРЖАВНА СЛУЖБА СПЕЦІАЛЬНОГО ЗВ'ЯЗКУ ТА ЗАХИСТУ ІНФОРМАЦІЇ УКРАЇНИ

АДМІНІСТРАЦІЯ ДЕРЖАВНОЇ СЛУЖБИ СПЕЦІАЛЬНОГО ЗВ'ЯЗКУ ТА ЗАХИСТУ ІНФОРМАЦІЇ УКРАЇНИ

Випускна робота

На тему

Розгортання керуючого proxy-сервера для підприємства програмними засобами Squid

Одеса 2012

Зміст

Реферат

Вступ

1. Загальні відомості про proxy-сервери

1.1 Опис впроваджуваної технології. Програмний продукт Squid

1.2 Вимоги замовника до проекту

2. Розробка стратегії впровадження та реалізації проекту

3. Установка і настройка proxy-сервера squid

3.1 Установка і настройка proxy-сервера

3.2 Настройка windows клієнтів

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

Перелік посилань

Структурна схема мережі підприємства

proxy сервер програмний squid

Реферат

Текстова частина випускної роботи: с.,

7 джерел.

Об'єкт дослідження - програмний пакет squid.

Мета дослідження - організація proxy-серверу для підприємства.

Метод дослідження - техніко-економічний із використанням комп'ю-терних технологій.

Для мережі проведено обґрунтування використання програмний пакет squid. Розроблено стратегію настройки proxy-серверу. Розглянуто питання пов'язані з настройкою proxy-серверу на прикладі конкретної організації в місті Львів.

PROXY-СЕРВЕР, ЛОКАЛЬНА МЕРЕЖА, КЕШУЮЧИЙ PROXY-СЕРВЕР, ACCESSCONTROL LIST, ПУЛ, ГЛОБАЛЬНА МЕРЕЖА, WINDOWS

Умови одержання випускної роботи: за дозволом проректора з навчальної роботи ОНАЗ iм. О. С. Попова.

Вступ

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

У корпоративних мережах доволі звичайна ситуація, коли, з одного боку, безліч користувачів на різних комп'ютерах користуються ресурсами мережі Інтернет, при цьому забезпечити належний рівень безпеки на цих комп'ютерах одночасно досить складно. Ще складніше змусити користувачів дотримуватися якогось "корпоративного стандарту", що обмежує можливості використання Інтернету (наприклад, заборонити використання певного типу ресурсів або закрити доступ до деяких адресами).

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

Найпростішим рішенням буде вирішити тільки певні методи доступу до Інтернет (наприклад, по протоколах HTTP і FTP) і визначити права доступу абонентів на одному сервері, а самим абонентам дозволити тільки звернення до цього сервера за спеціальним проксі-протоколом (підтримується всіма сучасними браузерами). Сервер ж, після визначення прав доступу, буде транслювати (проксувати) вхідні на нього HTTP-запити, направляючи їх адресату.

1. Загальні відомості про proxy-сервери

1.1 Опис впроваджуваної технології. Програмний продукт Squid

Проксі-сервер (від англ. Proxy - "представник, уповноважений") - служба, комплекс програм, в комп'ютерних мережах, що дозволяє клієнтам виконувати непрямі запити до інших мережних служб. Спочатку клієнт підключається до проксі-серверу і запитує який-небудь ресурс (наприклад, e-mail), розташований на іншому сервері. Потім проксі-сервер або підключається до зазначеного сервером та отримує ресурс у нього, або повертає ресурс з власного кешу (у випадках, якщо проксі має свій кеш). У деяких випадках запит клієнта або відповідь сервера може бути змінений проксі-сервером в певних цілях. Також проксі-сервер дозволяє захищати клієнтський комп'ютер від деяких мережевих атак і допомагає зберігати анонімність клієнта.

Найчастіше проксі-сервери застосовуються для наступних цілей:

· Забезпечення доступу з комп'ютерів локальної мережі в Інтернет.

· Кешування даних: якщо часто відбуваються звернення до одних і тих же зовнішніх ресурсів, то можна тримати їх копію на проксі-сервер і видавати за запитом, знижуючи тим самим навантаження на канал у зовнішню мережу і прискорюючи отримання клієнтом запитаної інформації.

· Стиснення даних: проксі-сервер завантажує інформацію з Інтернету і передає інформацію кінцевому користувачеві в стислому вигляді. Такі проксі-сервери використовуються в основному з метою економії зовнішнього трафіку клієнта або внутрішнього - компанії, в якій встановлено проксі-сервер.

· Захист локальної мережі від зовнішнього доступу: наприклад, можна налаштувати проксі-сервер так, що локальні комп'ютери будуть звертатися до зовнішніх ресурсів тільки через нього, а зовнішні комп'ютери не зможуть звертатися до локальних взагалі (вони "бачать" тільки проксі-сервер). Див також NAT.

· Обмеження доступу з локальної мережі до зовнішньої: наприклад, можна заборонити доступ до певних веб-сайтів, обмежити використання інтернету якимось локальним користувачам, встановлювати квоти на трафік або смугу пропускання, фільтрувати рекламу і віруси.

· Анонімізації доступу до різних ресурсів. Проксі-сервер може приховувати відомості про джерело запиту або користувача. В такому разі цільової сервер бачить лише інформацію про проксі-сервер, наприклад, IP-адресу, але не має можливості визначити дійсне джерело запиту. Існують також спотворюють проксі-сервери, які передають цільовим серверу помилкову інформацію про справжній користувача.

· Обхід обмежень доступу. Проксі-сервери популярні серед користувачів невільних країн, де доступ до деяких ресурсів обмежений законодавчо і фільтрується.

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

Види проксі-серверів:

Прозорий проксі - схема зв'язку, при якій трафік, або його частина, перенаправляється на проксі-сервер неявно (засобами маршрутизатора). При цьому клієнт може використовувати всі переваги проксі-сервера без додаткових налаштувань браузера (або іншої програми для роботи з інтернет).

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

· заборона / дозвіл на обробку JavaScript;

· використання Cookie;

· кодування веб-адреси і сторінки;

· заміна або очищення заголовка;

· і ряд інших, що залежить від конкретного додатка.

При кодуванні веб-адреси завантаження ресурсу застосовуються алгоритми Base64 і Rot13. Для кодування веб-сторінок використовується перетворення в HEX код всього текстового змісту веб-сторінки. Застосування цих методів дозволяє отримати доступ до сторінок із забороненим контентом і перейти по веб-адресою заблокованого Адміністратором. Адміністративними методами протидії використанню в локальних мережах веб-проксі можуть стати: посилення фільтрації контента і блокування адрес публічних веб-проксі.

Варто відзначити, що більшість хостерів забороняють встановлювати на дешевих тарифах віртуального хостингувеб-проксі з причини великого навантаження на сервер і активного споживання вхідного трафіку. Незважаючи на це обмеження, в Інтернет широко поширене створення цілих мереж веб-проксі, вони представляють собою велику кількість різних доменних імен, розміщених на одному або декількох IP-адресах виділених серверів. Такі мережі використовуються їх власниками для отримання прибутку від реклами, що розміщується на цих ресурсах.

Технічні подробиці проксі серверів.

Клієнтський комп'ютер має настройку (конкретної програми або операційної системи), відповідно до якої всі мережеві з'єднання по деякому протоколу відбуваються не на IP-адресу сервера (ресурсу), що виділяється з DNS-імені ресурсу, або безпосередньо заданий, а на ip-адреса ( та іншої порт) проксі-сервера. При необхідності звернення до будь-якого ресурсу з цього протоколу, клієнтський комп'ютер відкриває мережеве з'єднання з проксі-сервером (на потрібному порту) і здійснює звичайний запит, як якби він звертався безпосередньо до ресурсу. Розпізнавши дані запиту, перевіривши його коректність і дозволу для клієнтського комп'ютера, проксі-сервер, не розриваючи з'єднання, сам відкриває нове мережеве з'єднання безпосередньо з ресурсом і робить той же самий запит. Отримавши дані (або повідомлення про помилку), проксі-сервер передає їх клієнтського комп'ютера. Таким чином проксі-сервер є повнофункціональним сервером і клієнтом для кожного підтримуваного протоколу і має повний контроль над усіма деталями реалізації цього протоколу, має можливість застосування заданих адміністратором політик доступу на кожному етапі роботи протоколу.

Проксі-сервери є найпопулярнішим способом виходу в Інтернет з локальних мереж підприємств і організацій. Цьому сприяють такі обставини:

Основний використовуваний в інтернеті протокол - HTTP, в стандарті якого описана підтримка роботи через проксі;

· Підтримка проксі більшістю браузерів і / або операційних систем;

· Контроль доступу та облік трафіку по користувачам;

· Фільтрація трафіку (інтеграція проксі з антивірусами);

· Проксі-сервер - може працювати з мінімальними правами на будь ОС з підтримкою мережі (стека TCP / IP);

· Багато додатків, що використовують власні спеціалізовані протоколи, можуть використовувати HTTP як альтернативний транспорт або SOCKS-проксі як універсальний проксі, що підходить для практично будь-якого протоколу;

· Відсутність доступу до Інтернету по іншим (нестандартним) протоколам може підвищити безпеку в корпоративній мережі.

В даний час, незважаючи на зростання ролі інших мережевих протоколів, перехід до тарифікації послуг мережі Інтернет за швидкістю доступу, а також появою дешевих апаратних маршрутизаторів з функцією NAT, проксі-сервери продовжують широко використовуватися на підприємствах, так як NAT не може забезпечити достатній рівень контролю над використанням Інтернету (аутентифікацію користувачів, фільтрацію контента).

Squid (англ. squid - "") - програмний пакет, який реалізує функцію кешуючогопроксі-сервера для протоколів HTTP, FTP,Gopher і (в разі відповідних налаштувань) HTTPS. Розроблено співтовариством як програма з відкритим вихідним кодом (поширюється відповідно до GNU GPL). Всі запити виконує як один неблокіруемой процес введення / виведення.

Використовується в UNIX-like системах і в ОС сімейства Windows NT. Має можливість взаємодії з ActiveDirectory Windows Server шляхом аутентифікації через LDAP, що дозволяє використовувати розмежування доступу до інтернет ресурсів користувачів, які мають облікові записи на Windows Server, також дозволяє організувати "нарізку" інтернеттрафіку для різних користувачів. Використовується разом з движками Mediawiki на wikiхостингах. Використання кешуючогопроксі-сервера стає вигідно приблизно з 2000 відвідувачів на добу.

Сервер Squid розвивається протягом вже багатьох років. Забезпечує сумісність з більшістю найважливіших протоколів Інтернету.

Для контролю доступу до ресурсів та визначення ряду дій використовуються списки контролю доступу (англ. accesscontrollist, acl). Кожен ACL може складатися з кількох критеріїв (але тільки одного типу):

· адреса (мережа) джерела запиту, цілі запиту

· ім'я (доменне ім'я) джерела запиту, ім'я мети запиту

· частини URL запиту

· протокол

· порт (одержувача, відправника, самого squid'а)

· метод (POST або GET) при передачі даних по HTTP

· браузер (User-agent)

· ident (запит до робочої станції)

· Номер автономної системи відправника / отримувача (не для всіх випадків)

· Авторизація на проксі-сервер (див. нижче)

· Номер з'єднання (найчастіше використовується для обмеження кількості з'єднань)

· SNMP

· сертифікати користувача

· параметри запиту

· зовнішні обробники, ідентифікація

Squid підтримує кілька видів ідентифікації користувачів:

· По IP-адресі (або доменному імені вузла)

· За переданим реквізитами (логін / пароль)

· За ідентифікатором користувача агента (браузера)

· Для ідентифікації за логіном / паролем можливо використовувати:

· Звичайні логін / пароль

· NTLM-авторизацію

· Зовнішні програми авторизації (визначають формат авторизації).

Squid має можливість переписувати запитувані URL. Squid може бути налаштований так, щоб пропускати вхідні URL через процес редиректора виконуваного як зовнішній процес (подібно dnsserver), який повертає новий URL або порожній рядок, що позначає відсутність змін. Редиректор не є стандартною частиною пакета Squid. Редиректор надає адміністратору контроль за пересуваннями користувачів. Використання редиректора в поєднанні з прозорим проксінг дає простий, але ефективний контроль, над доступом до небажаних ресурсів (наприклад до розважальних ресурсів та соціальних мереж в корпоративній мережі, порнографії). Програма-редиректор повинна читати URL (один на рядок) зі стандартного входу і записувати змінені URL або порожні рядки на стандартний вихід. Потрібно зауважити, що програма-редиректор не може використовувати буферізірованний введення виведення. Squid дописує додаткову інформацію після URL, яку редиректор може використовувати для прийняття рішення.

Ще одним цікавим властивістю Squid'a є те, що він вміє працювати в режимі каскадний проксі сервер.

Тобто він може не тільки брати інформацію з інтернету, а й спочатку опитувати сусідів / батьків, на предмет наявності такої інформації у них в кеше, а тільки потім приймає рішення про завантаження даних, якщо вони відсутні, з інтернету. На малюнку вище, представлена ??наступна схема: всі користувачі знаходяться в одній мережі, група 2 виходить в інтернет через сервер squid 2, група 1 виходить в інтернет через squid 1, то в свою чергу шукає дані в кеші у себе, далі стукає до батька ( parent) за інформацією, squid 2 дивиться у себе в кеші, якщо не знаходить, то бере дані з інтернету. Відразу напевно виникне питання "а навіщо 2 проксі сервера? Навіщо використовувати каскадне проксінг?". Відповідей може бути багато, по-перше, це приріст продуктивності, т.к. не 1 сервер працює, а 2. По-друге, це дає можливість реалізовувати різні типи авторизації на сервері. Наприклад на squid 2 у нас буде жорстка аутентифікація по ip адресами, а на squid 1 буде прозора аутентифікація з пропуском в інтернет всіх бажаючих. До речі маленька замітка - Squid не вміє одночасно працювати в прозорому режимі і в режимі аутентифікації. Для тих хто не зрозумів, прозора аутентифікація - це вихід в інтернет без маніпуляцій з настройками в браузері. Цей режим схожий на те, як працює NAT. Але в даному випадку є 1 великий недолік - в прозорому режимі squid не працює з ssl, це особливість технології TCP / IP, тобто на https:// у вас зайти не вийде.

Рисунок 1.1 - Схема реалізації каскадного проксі-сервера

Цією можливістю (каскадне проксінг) можна скористатися і в разі, якщо у вас є 2 провайдера і ви вирішили не морочитися, щодо того, щоб виводити різних користувачів через різних провайдерів, через 1 squid, а поставили 2 squid сервера і розкидали користувачів по ним. Наприклад у нас падає інтернет на одному з провайдерів і щоб не бігати по всім клієнтам, настройки не змінювати, можна просто цей сервер squid, на якому зник інтернет, пустити через робітник, на час технічних робіт. І користувачі не помітять, і вам особливо нічого складного робити не доведеться, всього пару рядків додати і перезапустити сквид. Але й тут є 1 недолік, у вас через SSL дані не будуть передаватися, тому що він, squid, все одно буде намагатися безпосередньо вийти в інтернет, а не через батька. Це вирішується тим, що задається жорстке правило, пускати весь трафік тільки через батька. Даний момент докладніше і наочніше буде розглянуто в налаштуванні squid.

SQUID вміє не тільки розмежовувати користувачів за рівнем доступу, але ще й вміє обмежувати швидкість для різних груп або поодиноких користувачів. Ця система називається delay_pools, за допомогою якої б задаємо кількість "пулів", далі ми вказуємо який "пул", до якого класу належить, через delay_class, потім слід перерахування правил, які можуть входити в цей "пул" delay_access або знаком заперечення! які виключаються. Але якщо група не входить у правила дозволених, значить вона автоматично переходить в правила заборонених. До речі, знак заперечення! можна так-же використовувати і при формування "аклов". Ну і останнім описом йде визначення параметрів для пулу, який належить одному з класів delay_parameters

В squid існувало всього 3 класу, але з третім версією, з'явилося ще 2 нових, на жаль я не вникав в принцип їх роботи, тому описувати буду тільки 3 класичних класу. Але будьте впевнені, цих класів буде достатньо з повна! А комусь, для малої мережі, і зовсім вистачить одного 1го класу.

Рисунок 1.2 - Класифікація пулів

1й клас обмежує загальну швидкість для всіх хостів входять в певну групу.

2й клас обмежує загальну швидкість завантаження та швидкість завантаження індивідуальної машини. Якщо вам так буде простіше, то уявіть, що пули, це відра, то під 2м класі 1 загальне відро на мережу і всередині нього ще кілька відер на кожного користувача. Тобто якщо 1 користувач заб'є свій канал, то канали 2х інших користувачів будуть порожні.

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

Ну і зрозуміло, після всього це, описи авторизації, правил, пулів, слід останній блок значень, це рівень доступу. Описується він командою http_acces, застосовується для вказівки якими правилами дозволено ходити і куди ходити. Або навпаки, кому куди не можна. Так-же як і при роботі з "пулами" і "акламі" тут можна використовувати знак заперечення.

SAMS (SQUID AccountManagementSystem) - програмний засіб для адміністрування доступу користувачів до проксі-сервераSquid.

На даний момент SAMS налаштовує роботу редиректоров:

* Редиректор SAMS - редиректор, що працює безпосередньо з базами SAMS

* SquidGuard - дуже потужний редиректор.

* Стандартний SQUID - найпростіший редиректор, описаний в документації до SQUID

Види редикторів: редиректор SAMS. Написаний спеціально для SQUID, безпосередньо використовує інформацію, що міститься в базі даних. Дозволяє включити різне перенаправлення запитів для користувачів (регулюється шаблонами користувачів). Редиректор SAMS забезпечує:

* обмеження доступу користувачів до SQUID

* контроль часу доступу користувачів до SQUID

* обмеження доступу користувачів до заборонених ресурсів (або доступ користувачів тільки до дозволених ресурсів)

* перенаправлення запитів користувачів до банерів, лічильників і т. п.

РедиректорSquidGuard. Потужний редиректор з великими можливостями. До складу редиректора входять списки банерних, порно тощо доменів. SAMS додає в файл конфігурації SquidGuardsquidguard.conf налаштування на списки заборонених доменів і перенаправлення доступу SAMS. Налаштування на списки, що йдуть з SquidGuard не змінюються і не видаляються. При використанні редиректораSquidGuard в файл squid.conf заносяться acl, що дозволяють доступ всіх користувачів до SQUID. Обмеження доступу користувачів організовано засобами редиректора.

Стандартний SQUID. Цей редиректор описаний в документації на SQUID. Написаний на perl. Редиректор створюється після подачі команди на реконфигурирование SQUID, на основі списків перенаправлення запитів. Швидкий і легкий редиректор, але не розрізняє користувачів. При використанні цього редиректора, обмеження доступу користувачів за списками заборони доступу організовано з використанням ACL SQUID. При використанні редиректора SQUID або якщо редиректор не використовується зовсім, то існує можливість - при відключенні користувачів за перевищення трафіку у них залишається доступ до URL та IP адресами, прописаним у списку "Локальні домени".

Обмеження максимальної швидкості отримання користувачем (користувачами) в squid реалізовано за допомогою механізму delaypools (дослівно - "пули затримки"). Механізм обмеження швидкості працює за принципом басейну (звідки і назва pool (басейн)), в який "втікає" і "випливає" інформація. Окремі конфігуровані подібним чином області пам'яті називаються bucket (відро). У bucket є параметри: "ємність", "швидкість наповнення". Якщо користувач (користувачі) отримують інформацію на швидкості нижче, ніж "швидкість наповнення", то відро завжди повно. Якщо користувач короткочасно піднімає швидкість отримання інформації вище швидкості наповнення, то до моменту, поки відро не порожньо, він не обмежується за швидкістю, як тільки відро стає порожнім, клієнт отримує інформацію зі швидкістю наповнення відра. У разі наявності групових та індивідуальних відер, вони включаються послідовно.

Існує три типи (класу) delaypools:

· Єдине bucket (англ. aggregatebucket, class 1) обмеження на загальну споживану смугу для всієї групи. (Параметри: ємність басейну, швидкість наповнення).

· Єдине bucket з автоматичним формуванням індивідуальних bucket (англ. singleaggregatebucketaswellasan "individual" bucket, class 2). Індивідуальні відра формуються з бітів IP-адреси (c 25 по 32).

· Єдине bucket, мережеві bucket та індивідуальні відра. Мережеве bucket формується по бітам 17-24 IP-адреси.

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

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

Зворотне кешування. Однією з особливостей squid є можливість працювати в режимі "зворотного проксі" ("reverseproxy"), також відомого як "прискорювач" ("HTTP accelerator"). В цьому випадку замість кешування запитів декількох користувачів до безлічі сайтів, кешує запити безлічі користувачів до кількох сайтів. В цьому режимі прийнятий запит перевіряється на "динамічність" (чи потрібно кожен раз обробляти запит з нуля) і "вік" (чи актуальні ще дані). Якщо дані ще актуальні й не помінялися, то запит не передається серверу, а віддається з кешу squid'а. Таким чином істотно знижується навантаження на сервери. Крім того, "зворотний проксі" здатний розподіляти запити між кількома серверами, балансуючи навантаження або забезпечуючи відмовостійкість, тобто фактично надає функціональність, аналогічну кластеру.

Режим прозорого проксі-сервера. У поєднанні з деякими міжмережевими екранами і маршрутизаторами squid може працювати в режимі прозорого проксі (англ. transparentproxy). В цьому режимі маршрутизатор замість того, щоб відразу пересилати HTTP-запити користувача HTTP-сервера в Інтернеті, перенаправляє їх проксі-сервера, який може працювати як на окремому хості, так і на самому маршрутизаторі. Проксі-сервер обробляє запит (з можливою віддачею вмісту з кеша), це вміст прямує до запиту користувача, для якого воно виглядає як "відповідь" сервера, до якого адресувався запит. Таким чином, користувач може навіть не знати, що всі запити та відповіді пройшли через проксі-сервер. При такому підході проксінгаутентифікація не передбачена, оскільки прозорість проксінг це і має на увазі.

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

Недоліки. В режимі прозорості не проксуются FTP-і HTTPS-запити.

Основні опції програмного пакету Squid:опції аутентифікації.

TAG: auth_param. Використовується для визначення параметрів різних схем аутентифікації підтримуваних Squid-ом.

Format: auth_paramschemeparameter [setting].

Порядок в якому схеми аутентифікації представляються клієнту, залежить від порядку розташування схем в конфігураційному файлі. Перша по порядку схема, буде представлена ??першою. IE має баг (конфліктує з RFC 2617), пов'язаний з тим, що він використовує "basic"-схему авторизації, незважаючи на те, що в списку є більш безпечні схеми. Рекомендується використовувати той порядок схем, що встановлений за умовчанням. Якщо інші браузери мають складності ("не розуміють" пропоновані схеми), то встановіть "basic"-схемуаутентифікації першою в списку.

Повністю сконфігурована схема аутентифікації може бути відключена тільки після виключення і рестарту Squid-а.

Зміни можуть бути зроблені "на льоту" і активовані реконфігурацією Squid-а (Командою "reconfigure"?). Наприклад, Ви можете встановити інший "хелпер", але не розконфігурувати (відключити?) "Хелпер" повністю.

Changescanbemadeontheflyandactivatedwith a reconfigure. I.E. Youcan

Changeto a differenthelper, butnotunconfigurethehelpercompletely.

Запам'ятайте, хоча ця директива визначає як Squid проводить аутентифікацію, це не веде до автоматичної активації аутентифікації. Для використання аутентифікації ви повинні додатково використовувати ACL, заснований на логіні в тегах "http_access" ("Proxy_auth", "proxy_auth_regex" або "external" (зовнішній аутентифікатор).

З використанням змінної% LOGIN, використовуваної в форматі тега, браузер буде опитаний для авторизації першим же ACL, який зустрінеться в процесі обробки тега "http_access", а також буде повторно опитуватися на наявність нових облікових даних, якщо запит був відхилений в "proxy_auth" ACL. Аутентифікація не може бути використана при прозорому проксінгі, тому що клієнт "думає", що працює з оригінальним сервером безпосередньо, а не через проксі. Це обмеження накладає протокол TCP / IP, а не Squid. У портів, зазначених прапорами "transparent", "intercept" або "tproxy", аутентифікація відключена. Опції для "basic"-схемиаутентифікації. Команда "Program" визначає зовнішню програму, використовувану для аутентифікації. Така програма зчитує рядок містить "usernamepassword" і відповідає "OK" або "ERR" у нескінченному циклі. Відповіді "ERR" можна відстежити досліджуючи опис помилки, доступне у змінній% m на отриманній сторінці помилки. Якщо Ви використовуєте аутентифікатор, упевніться, що Ви маєте хоча б один ACL типу "proxy_auth". За замовчуванням, "basic"-схема не використовується, якщо не вказана програма аутентифікації.

Якщо ви хочете використовувати традиційну NCSA-аутентифікаціюпроксі, введіть у конфігураційний файл щось на зразок цього:

Auth_parambasicprogram / usr / local / libexec / ncsa_auth / usr / local / etc / passwd"Utf8" [on | off].

HTTP використовує кодування "iso-latin-1" в той час, коли деякі програми аутентифікації (наприклад, LDAP) очікують UTF-8. Якщо включити цю опцію, Squid буде транслювати "iso-latin-1" HTTP-запит в UTF-8 перед тим, як передати "username" і "password" програмі аутентифікації.

Число "Children" - кількість процесів аутентифікатора, які можуть бути запущені одночасно. Якщо їх буде дуже мало, то кожен новий клієнт, який бажає отримати доступ, буде очікувати поки не з'явиться вільний процес для аутентифікації користувача. Це уповільнює роботу Squid-а. Коли перевірка пароля зроблена через мережу, можливо ви захочете збільшити число процесів-аутентифікатором. Auth_parambasicchildren 5.

Число "Concurrency" - кількість паралельних запитів (каналів), які "хелпер" може обробляти. За замовчуванням 0, використовується "хелперамі", які підтримують один запит. В одиницю часу установка цього параметра змінює протокол, використовуючи включення номера каналу в початок рядка "запит / відповідь", що дозволяє одночасно відсилати кілька запитів.

Одному "хелперу" без очікування відповіді. Зміна параметра можливо тільки якщо відомо, що "хелпер" підтримує такий режим роботи. Auth_parambasicconcurrency 0.

Рядок "Realm" - визначає рядок, який буде відправлено користувачеві у вікні авторизації "Basic"-схеми (частина тексту, який побачить користувач, отримавши запит авторизації). Значення за замовчуванням відсутня. Може представляти собою назву проксі сервера, наприклад, "THE BEST proxy". Auth_parambasicrealm THE BEST proxy.

Час "Credentialsttl" - вказує Squid-у час валідності пари "username: password" для користувачів. Іншими словами, як часто "хелпер" буде повторювати авторизацію користувача. Установка маленьке значення, щоб участити переавторізацію короткодіючих (Shortlived) паролів. Зауважимо, що установка великого значення не впливає на сприйнятливість сервера до атак, якщо ви використовуєте систему одноразових паролів. Навіть використовуючи таку систему, ви будете уразливі до атак, якщо ви не будете додатково використовувати ACL "max_user_ip" в "http_access".

"Casesensitive" (on/off) - визначає, чи є "username" реєстрозалежні. Більшість баз даних регістру незалежні (тобто вважають слова user, USER і user ідентичними), дозволяючи використовувати верхній і нижній регістри, але деякі реєстрозалежні. Це має велике значення для обробки "max_user_ip" і схожих з ним ACL.Auth_parambasiccasesensitiveoff

Опції для "digest"-схемиаутентифікації.

"Program" - визначає програму, використовувану для зовнішньої аутентифікації. Така програма зчитує рядок, містить "username": "realm" і відповідає відповідним H (A1) значенням в шістнадцятковій системі ("hex"-код), якщо дані вірні, або "ERR", якщо користувач (або його H (A1) хеш) не існує. Див в RFC 2616 як визначається H (A1). Відповідь "ERR" можна відстежити досліджуючи опис помилки, доступне у змінній% m на поверненої сторінки помилки. За замовчуванням, якщо не вказана програма аутентифікації, "digest"-схема не використовується. Якщо ви хочете використовувати "digest"-аутентифікацію введіть в конфігураційний файл, щось на зразок цього:

Auth_paramdigestprogram / usr / local / bin / digest_pw_auth / usr / local / etc / digpass "Utf8" [on | off].

HTTP використовує кодування iso-latin-1, в той час як деякі движки аутентифікації, такі як LDAP, очікують UTF-8. Якщо ця опція включена, Squid транслюватиме HTTP iso-latin-1 в UTF-8 перед відправкою імені користувача і пароля "хелперу".

Рядок "Realm" - визначає "realm"-ім'я, яке буде повідомлено клієнту для схеми "digest"-аутентифікації(Частина тексту користувач побачить при появі запиту імені користувача і пароля). Значення за замовчуванням немає.

Auth_paramdigestrealmSquid proxy-cachingwebserver.

Всі унікальні параметри, пов'язані з використання "Digest"-аутентифікації, використовують. Щось, іменоване "nonce". Nonce - спеціальний рядок даних, яка час від часу змінюється. Під час процесу аутентифікації, сервер Squid надає "nonce"-значення клієнту. Клієнт використовує його при генерації дайджесту. Без даних "nonce", зловмисник може просто перехопити і відтворити дайджест, щоб отримати доступ до Squid.

"Nonce_garbage_interval" - визначає часовий інтервал, протягом якого "nonce"-и, надіслані до "Client_agent"-ам перевіряються на валідність.

"Nonce_max_duration" - визначає максимальний час, протягом якого відправлені "nonce"-и будуть дійсні.

"Nonce_max_count" - визначає скільки разів (макс.) Може бути використаний відданий "nonce".

"Nonce_strictness" [on | off] - визначає, чи буде Squid вимагати строгого збільшення на одиницю для підрахунку "Nonce", або простого збільшення для випадків коли вінзгенерований.

Користувальницьким агентом сигнал про використання "nonce" втрачає тобто, 1,2,4,6.

За замовчуванням вимкнено.

При установці "on" Squid повертає відповідь "401", якщо значення "nonce" не одне попереднє значення + 1'. При відключенні Squid допускає у значеннях "nonce" прогалини.

"Check_nonce_count" [on | off]. Якщо опція встановлена ??в "off", то для обходу помилок реалізації "qop" дайджест-схеми, в деяких версіях популярного браузера повністю відключається перевірка лічильника "nonce". За замовчуванням підрахунок "nonce" включений для захисту від атак пов'язаних з підбором аутентифікаційних даних.

"Post_workaround" [on | off] - обхідний шлях для деяких бажних браузерів, які відсилають некоректні. "Digest"-запити в POST-запитах при повторному використанні тих же "nonce" як отриманих раніше на GET-запит.

Thisis a workaroundtocertainbuggybrowserswhosendsanincorrectrequestdigest

In POST requestswhenreusingthesamenonceasacquiredearlieron a GET request.

Access controls - контроль доступу. External_acl_type. Визначає зовнішні ACL-класи, які використовують програми-"хелпери" для перегляду статусу. External_acl_type name, опції,FORMAT .. / Path / to / helper - аргументи хелпера. Вибір:Ttl = n TTL в секундах для кешування результатів(За умовчанням 3600 сек., тобто 1:00).Negative_ttl = n. TTL для кешування негативних "lookup"-ів.(За замовчуванням як у ttl).

1.2 Вимоги замовника до проекту

Компанія замовник вирішила зробити роботу своїх працівників більш продуктивною. Для цього дирекція фірми захотіла обмежити своїх працівників в доступі до популярних інтернет-ресурсів. Також потрібно було захистити внутрішню мережу від несанкціонованого доступу з зовнішніх мереж. При виборі системи враховувалось: стабільність роботи, мала ціна проекту, малий час установки і настройки системи. Замовник вибрав систему на Linux ядрі 2.4, ОС Debian. Proxy-сервербудемо ставити за допомогою програми squid. Вимоги замовника до проекту були такими:

- Закрити доступ співробітникам на певні сайти - соціальні мережі та інші.

- Закрити Mirc (є чат для співробітників).

- Прискорити роботу сервера кешуванням окремих видів файлів.

- Заборонити доступ всім на всі домени, які містять слово sex, porn,teen.

- Заблокувати доступ до тих URL, в яких зустрічаються ці слова.

- Заборонити всім доступ до мережі Інтернет з 18.00 до 07.00 годин кожен день.

- Дозволити клієнту А і тільки йому, доступ у "ранковий" час.

- Дозволити клієнту В і тільки йому, доступ у "обідній" час.

- Дозволити клієнту С і тільки йому, доступ у "вечірній" час.

- заборонити доступ клієнтам до web-сайту, чиє ім'я співпадає з шаблоном, описаним в "naughty_sites".

- дозволяє доступ клієнтам "validclients".

- блокує усі інші запроси.

- відторгає спробу підключення любого другого клієнта, за виключенням дозволених клієнтів.

2. Розробка стратегії впровадження та реалізації проекту

В цьому розділі ми розробимо стратегію впровадження. Установку проксі-сервераsquid я буду робити на операційній системі LinuxDebian6.0 основаною на ядрі версії 2.6. Клієнти працюватимуть на комп'ютерах з операційною системою Microsoft Windows.Найпростішим рішенням буде вирішити тільки певні методи доступу до Інтернет (наприклад, по протоколах HTTP і FTP) і визначити права доступу абонентів на одному сервері, а самим абонентам дозволити тільки звернення до цього сервера за спеціальним проксі-протоколу (підтримується всіма сучасними броузерами). Сервер ж, після визначення прав доступу, буде транслювати (проксіровать) приходять на нього HTTP-запити, направляючи їх адресату.

Squid може бути встановлений з вихідних текстів чи у вигляді dbm-пакета. Установка буде відбуватися з rpm пакета squid. Безпосередньо після установки Squid вже підтримує функції проксі, але приймає з'єднання тільки з того комп'ютера, на який встановлено. Для того, щоб можна було скористатися цим сервісом з інших комп'ютерів, необхідно змінити т. н. таблиці управління доступом (Access ControlLists, далі ACL), що знаходяться, як і більшість налаштувань Squid, у файлі / etc / squid / squid.conf. Файл цей забезпечений докладними коментарями та прикладами по всіх налаштувань у вигляді коментарів, наприклад, TAG: деяка настройка. Таким же чином там описані всі значення, виставлені за замовчуванням. Зокрема, для того, щоб Squid приймав з'єднання з усієї внутрішньої мережі, необхідно розкоментувати два рядки і підставити в них дійсний діапазон адрес нашої мережі; це програма, яка отримує HTTP / FTP запити клієнтів і по них звертаєтьсядо ресурсів Інтернет.

Застосування проксі-сервера (Squid) дає можливість використовувати фіктивні IP-адреси у внутрішній мережі (маскування), збільшує швидкість обробки запиту при повторному зверненні (кешування), забезпечує додаткову безпеку. Немає сенсу встановлювати проксі на своїй домашній машині, тому що функції кешування виконує браузер. Але проксі-сервер варто застосовувати лише в тому випадку, якщо у вашій мережі три-чотири комп'ютери, яким потрібен вихід в Інтернет. У цьому випадку запит від браузера до проксі-сервера обробляється швидше, ніж від проксі до ресурсів Інтернет, і таким чином збільшується продуктивність. До того ж, ми можемо сміливо встановити розмір кеша в браузерах клієнтів рівним нулю.

Squid кешує проксі для веб-клієнтів, що підтримує FTP, Gopher, і HTTP. На відміну від традиційних кешируючого програм, Squid всі запити виконує як один, неблокуємий процес введення / виведення. Squid зберігає часто запитувані дані в ОЗУ, кешує DNS запити, не блокується при виконанні DNS запитів, і не кешує невдалі запити. Також підтримує SSL, розширений контроль доступу і повну реєстрацію запитів. Використовуючи Інтернет кешу Protocol (ICP), кеши Squid можна розташувати ієрархічно для додаткового виграшу в пропускної здатності каналу.

Squid складається з - основної програми а, програми обробки DNS запитів dnsserver, програми скачування даних FTP ftpget, а також деяких інструментів управління. Коли запускається, він запускає задане число dnsserver-ов, кожен з яких працює самостійно, блокуючи тільки DNS-запити. Таким чином зменшується загальний час очікування відповіді DNS.

Squid бере свій початок з заснованого ARPA проекту Harvest.

Кешування об'єктів через інтернет - це спосіб зберігання запитаних з Інтернет об'єктів (наприклад, даних доступних по протоколах HTTP, FTP і Gopher протоколам) на сервері, що знаходиться ближче до запитуючій комп'ютера ніж вихідний. Браузери можуть потім використовувати Squid кеш як HTTP проксі-сервер, зменшуючи як час доступу, так і завантаження каналу; може бути встановлений з вихідних текстів чи у вигляді RPM-пакета. Установка RPM пакета SQUID дуже проста - для цього потрібно ввести команду мін-IH а-2.3.STABLE2-3mdk.i586.rpm.

Слід мати на увазі, що при обробці запиту на доступ до Squid всі рядки http_access файлу squid.conf проглядаються послідовно зверху вниз до першого рядка, що відповідає параметрам запиту. Це означає, що важливий порядок

Проходження рядків http_access.

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

Існує багато аналізаторів, журналів проксі серверів якпід Windows, так під NIX. Squid, на сьогоднішній деньнайбільш гнучкий з вільних проксі-серверів вналаштуванні і багатий за можливостями, хоча і в нього є недоліки. Маючи великий досвід організаціїкорпоративного доступу в Інтернет, і випробувавши різніаналізатори, для себе зупинився на двох готових рішеннях:

FreeSA і SARG одному самописні; підтримка різних форматів файлів журналів

(Squid, CLF,Postfix, qmail, communigatepro).

Основа роботиsquid:

1. Аутентифікаціяза паролем, гнучкий контрольдоступубезприв'язки доIP.

2.Невеликаекономіятрафіку.

3. ПовнийконтрльякіURLвідвідуютькористувачі.

4. Можливістьблокуваннязапитівпомаскам, наприклад, блокування порнографії.

5. Обмеженнячислазапитівта трафікучерезпулівзатримки.

При використанні проксі-сервера залишається деяка загроза безпеки, пов'язана з тим, що топологія внутрішньої мережі і активність її абонентів не маскуються. Наприклад, у протоколі HTTP використовуються заголовки (headers), значення яких заповнюються броузерами при відправленні запиту. Squid вміє видаляти небезпечні поля заголовка із запиту за допомогою настройки header_access або підміняти їх значення на інші, заздалегідь задані, за допомогою настройки header_replace. Варіанти використання цих налаштувань наведені в squid.conf в районі TAG: header_access і TAG: header_replace відповідно. Через видалення або підміни полів заголовків може порушитися зв'язок з деякими системами, що використовують значення цих полів для організації взаємодії та авторизації.

Http_port нам потрібен остільки, оскільки наш проксі сервер Squid повинен обслуговувати тільки комп'ютери нашої локальної мережі і бути невидимим для зовнішнього світу, щоб виключити можливість "поганим людям "зовнішньої мережі скористатися нашим каналом або трафіком, а у випадку, якщо будуть виявлені "діри" в коді проксі сервера Squid, скористатися ними.

Параметр http_access використовується для дозволу або заборони доступу до певних ресурсів, визначеними адресами або з певних адрес, до певних сайтів, з певних протоколів, портів і всього того, що безпосередньо зазначено за допомогою Acl (списків контролю доступу).

Заборона використання нашого проксі сервера, окрім як користувачами нашої локальної мережі:

Http_access allowlocalnet

Http_access denyall

В даному випадку слово allow є дозволом, а слово deny забороною, тобто ми дозволяємо доступ до проксі сервера Squid з адрес нашої локальної мережі і забороняємо доступ всім іншим.

Вивчаємо acl (списки контролю доступу).

Система управління доступом в проксі сервері Squid є дуже гнучкою і великою. Вона складається з елементів зі значеннями і списків доступу c

Зазначенням allow (дозвіл) або deny (заборона).

Можна взагалі не повідомляти користувачам мережі, що в ній використовується проксі-сервер. Якщо проксі-сервер - це й маршрутизатор, весь мережевий трафік в будь-якому випадку його не омине. При цьому можна засобами міжмережевого екрану всі звичайні HTTP-запити до віддалених серверів перенаправляти на вхід особливим чином налаштованого Squid. Із зовнішнього боку це виглядатиме звичайним проксі-сервером, а з боку користувача - нічим не відрізнятиметься від звичайної роботи в мережі.

В Squid існує гнучка схема фільтрації зовнішніх посилань. З її допомогою, наприклад, можна закрити доступ до певних сайтів і ресурсів на них, позбутися нав'язливої ??реклами (banners), посилань непристойного змісту і т. п. Вміст фільтрується за допомогою все тих же ACL і налаштувань http_access deny, приклади яких наведені в squid.conf. При завданні фільтрується URL або доменного імені сервера можна використовувати регулярні вирази, таким чином в одному рядку визначаючи фільтр для цілого класу адрес або доменних імен.

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

Безпосередньо після установки сервера він вже виконує кешируючого функції. Кешування дозволяє не тільки заощадити на оплаті трафіку, а й зменшити час доступу до ресурсів Інтернет. Проте слід розуміти, що зниження зовнішнього трафіку можливо тільки якщо один і той же ресурс був запитаний декількома користувачами протягом деякого проміжку часу. Якщо для користувача запити майже не перетинаються, зниження трафіку може бути незначним. Крім того, кешування неефективно в ситуації, коли повторний запит на більшість об'єктів приходить вже після того, як ці об'єкти витісняються з кешу більш новими. Якщо аналіз статистики показує, що відбувається саме це, можна спробувати збільшити обсяг кеш-інформації. Налаштування Squid, що відповідають за розмір кеша, наведені у файлі squid.conf в розділі, що починається словами optionswhichaffectthecachesize. Нарешті, кешування вхідного потоку даних унеможливлює "справедливу" оплату різними користувачами їх власного трафіку. Наприклад, якщо один користувач відвідує якісь сайти за порадою іншого, то його трафік буде здебільшого не виходити за межі сервера, на якому ресурси цих сайтів вже - по милості першого користувача - закешируваний.

Деякі дані (наприклад, дуже великі файли, автоматично змінюються WWW-сторінки, звуки і т. п.) кешувати невигідно: вірогідність повторного запиту протягом "терміну придатності" низька, а інших об'єктів витісняється багато. З іншого боку, вміст деяких сайтів може знадобитися кешувати в обов'язковому порядку (наприклад, для прискорення доступу). Ці властивості управляються, як звичайно, за допомогою ACL і налаштувань always_direct (без кешування) і never_direct (обов'язкове кешування). Наприклад, щоб запобігти кешування файлів, одержуваних по протоколу FTP (це, як правило, розумно), необхідно у відповідному місці squid.confрозкоментувати рядки.

Якщо запитуваний ресурс не знайдений в локальному кеші Squid, він може спробувати запросити його у "вищестоящих" серверів або у "сусідів" - замість того, щоб звертатися в Інтернет. Таким вищестоящим сервером (parentpeer) може бути сервер провайдера, а сусідом (siblingpeer) - сервер абонента, підключеного до того ж провайдера. Правила передачі об'єктів кеша і формування ієрархії серверів описані в документації. Розділ налаштувань, що відповідає за механізм обміну кешем, починається словами optionswhichaffecttheneighborselectionalgorithm.

Необхідно знати, що обмін вмістом кешу вимагає неодмінною авторизації доступу між серверами (щоб уникнути фальсифікацій та іншого виду атак). Всі параметри з'єднання сервера з сервером (налагодження cache_peer) записуються в текстовому вигляді, включаючи паролі, так що слід строго обмежити доступ до файлу настройки squid.conf.

В режимі accelerate сервер сам приймає ззовні HTTP-запити, адресовані, як правило на 80-й порт. Крім того, необхідно вказати ім'я сервера і порт, на який будуть проксіроваться запити. Це можна зробити, наприклад, так

Якщо необхідно якось обмежити доступ до внутрішнього серверу, це легко зробити, застосувавши відповідні ACL.

Ми маємо 150 комп'ютерів в нашій корпоративній мережі. Для їх підключення до проксі-серверу ми використаємо п'ять комутаторів. Чотири на 36 портів і один на 16 портів. Все це показано на схемі 2.1, яка приведена нижче. Наш сервер виступає в ролі фільтра для нашої корпоративної мережі, який забороняє проходження непотрібного трафіку в нашу мережу з глобальної мережі Internet. Проксі-сервер squid ми вибрали тому що він являється найбільш ефективним інструментом для керування трафіком. Його функції ми опишемо нижче, а також чого я вибрав саме проксі-сервер squid.

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

Навіщо потрібен squid на підприємстві:

коли необхідно прискорити роботу інтернету

коли всі співробітники підприємства відвідують одні й ті ж сайти, то squid кешує їх, тим самим частина даних беруться не з інтернету, а безпосередньо з серверадиректор (сисадмін) хоче бачити які сайти відвідують його підлеглі, а також які файли вони качають

необхідно заблокувати певні сайти або закачування певних файлів

необхідно налаштувати роботу інтернету на підприємстві в певні години робочого дня

необхідно розподілити завантаженість каналу між користувачами

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

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

Після установки - відредагуємо конфігураційний файлsquid.conf.

І внесемо в нього відповідні зміни за умови, що у нас локальна мережа

192.168.0.0/24, а сервер має адресу 192.168.0.1

Можна вказати абсолютно будь-який порт, але краще залишити за замовчуванням. transparent - вказує на те, що сервер буде "прозорим" для користувачів. Якщо слово transparent не вказувати, тоді доведеться вручну у кожного користувача прописувати адресу proxy-сервера і порт 3128, а це на мій погляд не зручно.

Після розділу "TAG: acl" і перед розділом "TAG: http_acces" пишемо наступне acl our_networks src 192.168.0.0/24

Цією рядком ми створюємо мережу 192.168.0.0/24 з назвою our_networks, щоб в подальшому дозволити користуватися proxy-сервером тільки з локальної мережі 192.168.0.0/24

В кінці розділу "TAG: http_access" перед рядком "http_access" deny all "пишемо наступнеhttp_access allow our_networks. .

Цією рядком ми дозволяємо мережі з ім'ям our_networks користуватись proxy-сервером.

Додаємо правило в iptables. Перенаправляємо весь трафік з портів 80, 8080 на proxy-сервер 192.168.0.1:3128. Перезапускаємо squid командою.



Рисунок 2.1 - Структурна схема мережі підприємства

3. Установка і настройка proxy-сервера squid

3.1 Настройка proxy-сервера

Установка squid:

cd / usr / src /

gunzip squid-2.3.STABLE2-3-src.tar.gz

tar xvf squid-2.3.STABLE2-3-src.tar.gz

cd squid

. / configure - prefix = / usr / local / squid

make all

make install

Лістинг 3.1 - Установка squid

Squid буде встановлений в каталог, заданий ключем prefix - / usr / local / squid.Параметр http_access використовується для дозволу або заборони доступу

до певних ресурсів, визначеними адресами або з певних адрес, до певних сайтів, з певних протоколів, портів і всього того, що безпосередньо зазначено за допомогою Acl (списків контролю доступу).

Додамо новий Acl:

aclLocalNetsrc 192.168.0.0/24

Пишемо в файлі конфігурації:

http_port 192.168.0.1:3128

У нас проксі сервер Squid розташований за адресою 192.168.0.1 на порту 3128.Наступнадія, буде заборона використання нашого проксісервера, всім окрім як користувачами нашої локальної мережі:

http_access allowLocalNet

http_access denyall

В даному випадку слово allow є дозволом, а слово deny забороною, тобто ми дозволяємо доступ до проксі сервера Squid з адрес нашої локальної мережі і забороняємо доступ всім іншим.

Я дозволю Андрію Ковалеву (Kovalev) і відділу адміністрування (Admins) доступ до нашого проксі серверу, а всім іншим заборонимо: