Будет ли обратный прокси-сервер перед веб-сервером улучшать безопасность?

Сторонний специалист по безопасности рекомендует использовать обратный прокси-сервер перед веб-сервером (все размещенные в демилитаризованной зоне) в качестве наилучшей меры безопасности.

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

Тем не менее, поскольку обратный прокси-сервер активно переключает HTTP между пользователем и внутренним веб-сервером, он не обеспечивает какой-либо меры предотвращения взлома самого веб-сервера. Другими словами, если ваше веб-приложение имеет дыру в безопасности, прокси-сервер не будет обеспечивать какой-либо значимый уровень безопасности.

И учитывая, что риск атаки на веб-приложение намного выше, чем риск атаки на прокси-сервер, действительно ли много выигрывают, если добавить дополнительный блок в середине? Мы не будем использовать какие-либо возможности кэширования обратного прокси-сервера - просто тупой инструмент для перемещения пакетов назад и вперед.

Есть что-то еще, что я здесь скучаю? Неужели инспекция HTTP-пакетов обратного прокси настолько хороша, что может обнаруживать значимые атаки без существенных узких мест в производительности, или это просто еще один пример Security Theater?

Обратный прокси-сервер MS ISA FWIW.

Apache имеет mod_security, который будет обнаруживать обычные атаки безопасности. Существует также mod_cband, который может ограничивать используемую полосу пропускания. Я не удивлюсь, если бы у ISA было что-то подобное. Без каких-либо проверок HTTP-трафика, проходящего через прокси-сервер, все это немного бессмысленно с точки зрения безопасности.

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

ISA Server может искать и предотвращать различные эксплойты HTTP и предотвращать их попадание на веб-сервер. В то время как большинство современных HTTP-серверов больше не используются, это имеет дополнительное преимущество, заключающееся в том, что этот трафик не отправляется на веб-сервер.

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

Обязательно возьмите профи, которые этот человек дает на ISA, и сравните его с тем, сколько дополнительных затрат будет стоить на управление и запуск ISA по сравнению с преимуществами.

Будет ли обратный прокси-сервер перед веб-сервером улучшать безопасность?

Обратный прокси-сервер дает вам пару вещей, которые могут сделать ваш сервер более безопасным.

• Место для мониторинга и регистрации того, что происходит отдельно от веб-сервера
• Место для фильтрации или межсетевого экрана отдельно от вашего веб-сервера, если вы знаете, что какая-то область вашей системы уязвима. В зависимости от прокси вы можете фильтровать на уровне приложения.
• Еще одно место для реализации списков ACL и правил, если вы по какой-то причине не можете быть достаточно выразительными на своем веб-сервере.
• Отдельный сетевой стек, который не будет уязвим так же, как ваш веб-сервер. Это особенно верно, если ваш прокси от другого поставщика.
  • Использование установки Apache в качестве прокси-сервера перед сервером Apache, вероятно, не так полезно, как что-то вроде Squid перед Apache.

Обратный прокси-сервер без фильтрации автоматически не защищает вас от всего, но если система, которую вы хотите защитить, имеет высокую стоимость, то добавление обратного прокси-сервера может стоить затрат на поддержку и производительность.

Он может защитить ваш сервер приложений от атак, основанных на неправильных HTTP-запросах ... Особенно, если на обратном прокси-сервере (а не на сервере приложений) возможно точно настроить внешний вид хорошего запроса и не пропустить плохие запросы. Если вы скажете ему, как выглядят плохие запросы, это почти наверняка будет бесполезным. Другими словами, он может защитить от атак переполнения буфера, но не от внедрения SQL.

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

По сути, обратные прокси-серверы скрывают вашу инфраструктуру от мира. Так что это в основном случай безопасности по неизвестности, если только ваш веб-сервер действительно неуправляем и не защищен.

Он также может защитить ваши веб-серверы от некоторого вида DOS (распределенного отказа в обслуживании), особенно если ваш сайт «тяжелый», выступая тогда в качестве слоя кэширования.

Он также имеет некоторые недостатки: он скрывает от вашего приложения настоящий IP-адрес клиента. Это заставит вас потреблять больше мощности сервера и добавить слой вещей, которые могут сломаться. Помните, что ваш обратный прокси-сервер должен обрабатывать больше соединений (обычно в два раза больше: соединения с клиентами и соединения с вашим веб-сервером).

В конце концов, обратный прокси-сервер не избавит вас от необходимости иметь безопасный веб-сайт.

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

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

Я не думаю, что кто-то еще говорил о том, что вам не нужно открывать какие-либо внешние IP / порты через внешний брандмауэр. Хорошая обратная прокси-система инициирует обмен данными внутри вашей сети с сервером в демилитаризованной зоне, защищая сети от прямых атак. Это, однако и как уже говорили другие, не защитит вас от плохо написанного заявления.