Проксі-сервер

Матеріал з Фізмат Вікіпедії
Перейти до: навігація, пошук

Визначення проксі

Проксі-сервер (відомий також як шлюз додатків) являє собою додаток, що виступає для трафіку в якості посередника між надійною мережею і ненадійною мережею. Це не знімає необхідності застосування брандмауера для управління трафіком на IP-рівні, щоб не передбачати наявність брандмауера прикладного рівня. Слово "proxy", як і безліч інших стали популярними комп'ютерними термінами англійських слів, можливо, втратило для деяких з нас своє оригінальне значення. Відповідно до словника, proxy - це хтось (чи щось), уповноважений діяти від імені його клієнта і "доставляє" клієнту певні предмети. Можна уявити собі посередника як довірену особу або посла, яким наказано знаходитися десь, де не може безпосередньо знаходитися їхній клієнт з причин незручності або безпеці. Посли звичайно знають місцеву мову і звичаї, можуть призвести недосконалий запит клієнта у форму, допустиму в місцевому масштабі іншої зони, і, звичайно, можуть перевести назад отриману відповідь. У комп'ютерних поняттях такий "посол" може отримувати https-запити по порту 443 і перетворювати їх у http-запити по порту 80. Проксі в більш повсякденних, практичних комп'ютерних термінах є процесами, запущеними на комп'ютерах, яким, як правило, надано доступ (в брандмауері)в більш ніж одній зоні. Саме ця здатність робить їх корисними. У типовому випадку проксі просто буде працювати від імені свого користувача на місці перекриття зон (в образі програми), виконуючи та приймаючи щось із зони, з якою за інших обставин заборонено встановлювати контакт або запитувати що-небудь з боку окремих процесів та користувачів з іншої зони . З іншого боку, на проксі можна подивитися з точки зору "людини посередині".Однією з фундаментальних концепцій загальної безпеки (не тільки в криптографії) є концепція атаки з боку "(поганого) людини посередині", яка полягає в перехоплення та ретрансляції переданої між двома сторонами інформації третє, незваною, "поганою" стороною. Проксі можуть сприйматися як "хороші" приймачі (слухачі) інформації або як "люди посередині". Це означає, що вони перехоплюють інформацію, ретранслюють її далі, але з деякою визначеною і корисною для мережевої інфраструктури метою.

Типи проксі

Часто надане для проксі обладнання насправді виконує або підтримує безліч типів проксі-сервісів. Наприклад,проксі-сервер може давати можливості кешування і аутентифікації на додаток до основної функції забезпечення мережевого посередництва для додатків.В більшості випадків трактують ці ключові можливості проксі як окремі їх типи для полегшення подальшого розгляду. Є такі типи проксі: <p align="justify">* як переказують проксі (forward proxies);

* прозорі проксі (transparent proxies);

* кешуючі проксі (caching proxies);

* проксі забезпечення безпеки (security proxies);

* зворотні проксі (reverse proxies).

1)Як переказують проксі

Які переказують проксі є проксі-сервером, який допомагає користувачам з однієї зони безпеки виконувати запити контента з "наступною" зони, дотримуючись напрямку, яке зазвичай (але не обов'язково) є що виходить (це означає, що клієнт знаходиться всередині, а сервер де-то в відкритому Інтернеті). З точки зору безпеки простий проксі має на меті забезпечення безпеки, що складається в приховуванні найменування (у термінах топології внутрішньої мережі) робочої станції або процесу запитуючої користувача. Він може також застосовуватися для приховування деяких інших атрибутів сеансу користувача. Типовим прикладом цього типу є корпоративні проксі, які обслуговують внутрішніх користувачів за допомогою дозволу доступу на зовнішні сайти для Web-браузера або будь-якого іншого виду взаємодії з Інтернетом. З точки зору топологій які переказують проксі завжди є обмеженя в термінах мережевої швидкості по відношенню до користувача через більш повільного WAN-з'єднання (з'єднання з глобальною мережею), яке зазвичай відділяє проксі від реального контенту в Інтернеті.

2) Прозорі проксі

Прозорі проксі є проксі-серверами, які "знаходяться тут", але не інформують користувачів в прямій формі про те, що вони тут знаходяться. В пересилаючих проксі зазвичай існують Linux/UNIX блоки, які слухають весь трафік по певному протоколу для певного сегмента мережі та перехоплюють трафік, хоча для користувача процес насправді не знає про їх існування.Фактично користувальницький процес не спілкується з проксі, але спілкується з іншим (кінцевим) сайтом, а проксі, по суті, стає "людиною посередині", яка "зламує" з'єднання. Проксі є непрозорими,коли користувачі знають про те, що вони спілкуються через проксі, тому що вони звертаються (мовою проксі: HTTP) до проксі. Іншими словами, якщо я оголосив свій проксі як proxy.mydomain.com, то після цього мої процеси будуть спілкуватися з proxy.mydomain.com, запитуючи його про встановлення контакту з кінцевим адресою призначення моїх запитів.Існує необхідність спілкування на "мові проксі" (HTTP), а також передача йому куди "йти" і звідки "принести" необхідний контент. Ви можете мати оголошені, непрозорі проксі, які автоматично оголошені, сконфігуровані або виявлені. Незалежно від того, як вони були оголошені, ці проксі є видимими і відомими для запитувача користувача або процесу. Іншими словами, не важливо, як ви або ваш процес дізналися про існування проксі, які причини того, що ви дізналися про існування проксі і про те, що ви спілкуєтеся з проксі. Прозорі проксі самі по собі не є насправді типом проксі, швидше за будь-який проксі є або прозорим, або оголошеним за проектом.

3) Кешуючі проксі

Кешуючі проксі, як зазначено в їхній назві, є проксі-серверами, які налаштовані на повторне використання кеш-образів контенту, коли це можливо. Коли кеш раніше частину контенту недоступна, то проводиться її вибірка та використання в контенті, а також зі спробою її кешування. Найбільш важливим аспектом для кешуючих проксі є необхідність забезпечення того, що кешуючі проксі кешують тільки те, що на справді можна кешувати. Динамічно, регулярно змінювати контент не найкращий вибір для кешування, так як це може вплинути на стабільність програми, заснованого на цьому контенті. У разі HTTP-контенту заголовки HTTP відображають можливість кешування контенту за допомогою покажчиків "cache". У більшості випадків які переказують проксі конфігуруються також для роботи в якості кешуючих проксі. Це явище використовується настільки часто, що компанія IBM включила це в назву компонента свого Edge Server: IBM Caching Proxy. Проксі-сервер (відомий також як шлюз додатків) являє собою додаток, що виступає для трафіку в якості посередника між надійною мережею і ненадійною мережею. Це не знімає необхідності застосування браузера для управління трафіком на IP-рівні, щоб не передбачати наявність браузера прикладного рівня.


2.jpg


4) Проксі забезпечення безпеки

'В якості вищого прояву необхідної для простих проксі функціональності проксі-сервери можуть бути налаштовані для приведення у виконання політик безпеки. Такі проксі забезпечення безпеки можуть обробляти (або виступати в якості посередників при обробці) запити аутентифікації та авторизації. У цих випадках автентифікація користувача клієнта і авторизація клієнта для доступу до певного контенту контролюється самим проксі-сервером. Далі мандат безпеки посилається від проксі до кінцевих серверів із запитом, а кінцевий сервер повинен бути налаштований на надання довіри що надається проксі мандату. Існує багато різних продуктів і пропозицій, а також безліч топологій на вибір, але з точки зору виконання проксі-функцій безпека є додатковою функцією, яку може виконувати проксі. У більшості випадків функціональні можливості щодо забезпечення безпеки можуть бути додані стандартні проксі у вигляді додаткового програмного модуля [plug-in (плагін)] (наприклад, IBM Tivoli WebSeal Plug-In для IBM WebSphere Edge Server). Існують також і окремі продукти, такі, як IBM Tivoli Access Manager for e-Business, які служать тільки як проксі забезпечення безпеки. В якості вищого прояву необхідної для простих проксі функціональності проксі-сервери можуть бути налаштовані для приведення у виконання політик безпеки. Такі проксі забезпечення безпеки можуть обробляти (або виступати в якості посередників при обробці) запити аутентифікації та авторизації. У цих випадках автентифікація користувача клієнта і авторизація клієнта для доступу до певного контенту контролюється самим проксі-сервером. Далі мандат безпеки посилається від проксі до кінцевих серверів із запитом, а кінцевий сервер повинен бути налаштований на надання довіри що надається проксі мандату. Існує багато різних продуктів і пропозицій, а також безліч топологій на вибір, але з точки зору виконання проксі-функцій безпека є додатковою функцією, яку може виконувати проксі. У більшості випадків функціональні можливості щодо забезпечення безпеки можуть бути додані стандартним проксі у вигляді додаткового програмного модуля [plug-in (плагін)] (наприклад, IBM Tivoli WebSeal Plug-In для IBM WebSphere Edge Server). Існують також і окремі продукти, такі, як IBM Tivoli Access Manager for e-Business, які служать тільки як проксі забезпечення безпеки.

5) Зворотні проксі

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

 Зворотні проксі і прозорість 

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


1.jpg


'Сервери безпеки - зворотні проксі [Reverse Proxies Secure Servers (RPSS)] з'єднують в одному блоці (або продукт) функції "чистих" зворотних проксі і функції проксі забезпечення безпеки, які були описані раніше. Найчастіше такі продукти RPSS будуть мати у зворотному проксі вбудований компонент, що обробляє запити управління доступом та авторизації і об'єднаний з кінцевою системою управління доступом підприємства, яка фактично перевіряє права користувача або клієнта на доступ і авторизацію. Цей вбудований компонент іноді називають лезом (blade1)). Приміром, як рішення для забезпечення безпеки на підприємстві ви можете використовувати IBM Tivoli Access Manager, але у вас є вибір у тому, яке лезо використовувати на рівні проксі (WebSeal або більш "легкий" плагін, іноді званий WebSeal-lite).

Тестування різних "дірок"

При створенні і побудові нової інфраструктури зворотних проксі треба протестувати всі шляхи через цю інфраструктуру. Коли введено в дію більшість зворотних проксі, то мається на увазі, що через брандмауер дозволено проходити тільки трафіку, пропущеного через зворотний проксі і що через зворотний проксі дозволено проходити тільки трафіку певних типів. На додаток до перевірки того, що всі бажані вами зв'язку працюють, переконайтеся в тому, що всі інші зв'язку не працюють. Повинно працювати тільки те, що дозволено явно, все інше не має працювати. Загальною проблемою розгорнутих систем є невдачі в дійсному "закриття" всіх альтернативних і прямих маршрутів що переносять об'єкти до кінцевих серверів. Перевірка прослуховує адрес. Тому можна проконтролювати, чи працює проксі і за якими портами він працює, шляхом перевірки проксі-сервера на предмет наявності процесу, прослуховуючого передбачувані порти. Корисно також перевіряти, щоб проксі не був випадково налаштований на прослуховування більшої кількості IP-адрес, ніж планувалося. Для перевірки на наявність прослуховуючого процесу для окремого порту (і для якого віддаленого адреси)можна використовувати команду операційної системи NETSTAT. netstat-an | find "LISTEN" | find "8080" 1)TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING Отже 0.0.0.0:8080 (або *.*: 8080)є локальною (першою) адресою, як показано, то це означає, що проксі прослуховує всі TCP / IP-адреси, оголошені і дозволені на локальній машині. Іншими словами, у разі наявності комп'ютера, який має більш однієї мережевої карти та IP-адреси, запитувач може з'єднатися з будь-яким із цих адрес і взаємодіяти через проксі. Це важливо перевіряти, оскільки іноді надзвичайно важливо прослуховувати специфічні адреси. Наприклад, з причин безпеки можна віддати перевагу прослуховуваню 127.0.0.1: xx на предмет наявності трафіку в тому ж самому сервері, доступ до якого має здійснюватися тільки через локальний зворотний проксі, і не прослуховувати зовнішню IP-адресу сервера. Недопущення переповнення кешу при використанні кешуючого проксі. Кешуючі проксі кешують те, що кешуємо, і не кешує те, що некешуємо. Результати ігнорування інструкцій щодо невиконання кешування з боку проксі-серверів, сконфігурованих на "збереження пропускної спроможності", можуть лежати в діапазоні від проблем аутентифікації до некоректного функціонування механізму єдиної авторизації [single sign on (SSO)], до відмови у функціонуванні ключових елементів функціональних можливостей , таких, як інформованість Sametime. Продукти Lotus сильно покладаються на те, що проксі не допускають переповнення кеша некешіруемим контентом, в іншому випадку результати будуть дійсно непередбачуваними. Якщо в процесі налагодження з'єднання між двома об'єктами, скажімо Алісою і Бобом, є хоч найменша підозра на те, що хтось (люди з вашої дружньої мережі або навіть ваш інтернет-провайдер) міг настроїти прозорий проксі посередині між Алісою та Бобом, деякі з цих прозорих які переказують проксі допускають переповнення кеша або агресивно кешуючу контент, що означає, що вони налаштовані на збереження пропускної здатності, причому не важливо якої. Відповідно вони надходять, як "вони вважають за краще" або як "більш інтелектуальні проксі", ігноруючи насправді інструкції "не кешувати (no-cache)" і "закінчення строку (expires)", які може задавати контенту Web-сервер.

Відстеження IP-адрес клієнтів

За замовчуванням багато зворотні проксі-сервери будуть приховувати справжній IP-адреса клієнта при виконанні запитів кінцевих серверів. Відповідно, буде здаватися, що всі запити йдуть з одного й того ж IP-адреси. Параметри забезпечення конфіденційності багатьох зразків проксі дозволяють наявність додаткових заголовків HTTP для передачі їх поряд із запитами. Таким чином, ви можете дозволити пересилання IP-адреси клієнта серверу призначення. При цьому до запиту додається значення додаткового заголовка HTTP, що містить дійсний IP-адреса запитувача клієнта. Дане явище має велике значення для забезпечення безпеки, тому що дозволяє вам відстежувати і усувати неполадки в будь-яких клієнтських з'єднаннях. Відключення пошуку імені з використанням DNS. Багато проксі-серверів дозволяють з'єднуються клієнтам здійснювати пошук імені з використанням DNS. Ця опція є причиною того, що проксі-сервер перетворює кожен вхідний IP-адреса клієнта в ім'я хоста, результатом чого є непродуктивні витрати в обробці даних на сервері. Якщо не брати до уваги причини з області забезпечення безпеки і протоколювання, які спонукають робити це, то дана опція звичайно повинна бути відключена. Ведення журналів та моніторинг вашого проксі. Проксі-сервери розміщуються в зовнішніх зонах, які залишають їх відкритими за наявності підвищеного рівня можливості проведення атак з боку потенційних хакерів. Тому потрібно регулярно здійснювати протоколювання подій та моніторинг проксі-систем.


Джерела:

1) http://smarthost.kiev.ua/solutions/proxy.html

2) http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%BA%D1%81%D0%B8-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80