Чи покращить безпеку зворотний проксі перед веб-сервером?

Сторонній фахівець із питань безпеки рекомендує запустити зворотний проксі перед веб-сервером (який розміщений у DMZ) як найкращий захід безпеки.

Я знаю, що це типова рекомендована архітектура, оскільки вона забезпечує інший рівень безпеки перед веб-додатком, щоб запобігти хакерам.

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

А враховуючи, що ризик нападу на веб-додаток набагато вищий, ніж ризик нападу на проксі, чи дійсно багато чого виграєте, додавши додатковий ящик посередині? Ми б не використовували жодну з можливостей кешування зворотного проксі-сервера - просто тупий інструмент для перенесення пакетів назад і назад.

Чи є ще щось, чого мені тут не вистачає? Перевірка HTTP-пакету зворотного проксі-сервера настільки хороша, що вона може виявляти значущі атаки без великих вузьких місць або це лише ще один приклад театру безпеки?

Зворотний проксі - це MS ISA fwiw.

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

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

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

Крім того, ISA може полегшити виконання таких дій, як додавання прискорення SSL та попередня авторизація користувачів до різних URL-адрес. Він навіть може виконувати роль балансира навантаження, щоб ви могли легко додавати більше веб-серверів, не використовуючи окремий апаратний балансир завантаження.

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

Чи покращить безпеку зворотний проксі перед веб-сервером?

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

• Місце для моніторингу та реєстрації того, що відбувається, окремо від веб-сервера
• Місце для фільтра або брандмауера окремо від вашого веб-сервера, якщо ви знаєте, що деяка область вашої системи вразлива. Залежно від проксі, ви можете фільтрувати на рівні програми.
• Ще одне місце для впровадження ACL та правил, якщо ви не можете з якихось причин висловитись на своєму веб-сервері.
• Окремий мережевий стек, який не буде вразливим так само, як ваш веб-сервер. Особливо це стосується вашого проксі-сервера від іншого постачальника.
  • Використання налаштування Apache як проксі-сервера перед сервером Apache, ймовірно, не настільки корисне, як щось на зразок кальмарів перед Apache.

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

Це може захистити ваш сервер додатків від атак, заснованих на поганих HTTP-запитах ... Особливо, якщо на зворотному проксі (а не на сервері додатків) можливо налаштувати саме те, як виглядає хороший запит, і не допускати поганих запитів. Якщо вам доведеться сказати, як виглядають погані запити, це майже напевно буде марним. Іншими словами, він може захищати від атак переповнення буфера, але не від ін'єкції SQL.

Переважно це звучить як театр безпеки. Ви найняли консультанта з безпеки, і вони повинні вам сказати, що потрібно зробити, щоб покращити вашу безпеку. Навряд чи зловмисник коли-небудь увірветься у зворотний проксі, і якщо вони просто обійдуть його, вони завжди можуть звинуватити вас; тому це безпечна рекомендація.

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

Він також може захистити ваших веб-серверів від якогось DOS (розповсюдженого відмови в обслуговуванні), особливо якщо ваш веб-сайт "важкий", він виступає в якості шару кешування.

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

Зрештою, зворотний проксі-сервер все одно не пошкодить вас мати безпечний веб-сайт.

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

http://www.apsis.ch/pound/

Одна з переваг, про яку я не думаю, що хтось інший говорив, - це те, що вам не потрібно відкривати будь-які зовнішні IP / порти через зовнішній брандмауер. Хороша система зворотного проксі-сервера ініціює зв'язок із внутрішньої мережі до сервера в DMZ, захищаючи мережі від прямих атак. Це, однак, як і інші сказали, не захистить вас від погано написаної програми.