Сторонний специалист по безопасности рекомендует запускать обратный прокси-сервер перед веб-сервером (все размещены в DMZ) в качестве наилучшей меры безопасности.
Я знаю, что это типичная рекомендуемая архитектура, поскольку она обеспечивает еще один уровень безопасности перед веб-приложением для предотвращения хакеров.
Однако, поскольку обратный прокси-сервер с радостью передает 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 по сравнению с преимуществами.
Это может защитить ваш сервер приложений от атак, основанных на неверных HTTP-запросах ... Особенно, если на обратном прокси (а не на сервере приложений) можно точно настроить, как выглядит хороший запрос, и не пропускать плохие запросы. Если вам нужно рассказать ему, как выглядят плохие запросы, это почти наверняка будет бесполезным. Другими словами, он может защитить от атак переполнения буфера, но не от SQL-инъекции.
В основном это звучит как театр безопасности. Вы наняли консультанта по безопасности, и он должен сказать вам, что делать, чтобы повысить вашу безопасность. Маловероятно, что злоумышленник когда-либо проникнет в обратный прокси-сервер, и если он просто обойдет его, он всегда сможет обвинить вас; так что это безопасная рекомендация.
По сути, обратные прокси-серверы скроют вашу инфраструктуру от мира. Таким образом, это в основном случай защиты от неизвестности, если только ваш веб-сервер действительно неуправляемый и незащищенный.
Он также может защитить ваши веб-серверы от некоторого вида DOS (распределенного отказа в обслуживании), особенно если ваш веб-сайт «тяжелый», действуя в этом случае как слой кеширования.
У него также есть некоторые подводные камни: он скроет от вашего приложения реальный IP-адрес клиента. Это заставит вас потреблять больше мощности сервера и добавит слой вещей, которые могут сломаться. Помните, что ваш обратный прокси-сервер должен будет обрабатывать больше подключений (обычно в два раза больше: подключений к клиентам и подключений к вашему веб-серверу).
В конце концов, обратный прокси-сервер в любом случае не избавит вас от безопасного веб-сайта.
Я думаю, что Zoredache дал очень хороший ответ о преимуществах обратного прокси. Я использовал Pound, который представляет собой обратный прокси, балансировщик нагрузки и интерфейс HTTPS.
Одно из преимуществ, о котором я не думаю, что кто-то еще говорил, заключается в том, что вам не нужно открывать какие-либо внешние IP / порты через внешний брандмауэр. Хорошая обратная прокси-система инициирует обмен данными изнутри вашей сети с сервером в демилитаризованной зоне, защищая сети от прямых атак. Это, однако, и как говорили другие, не защитит вас от плохо написанного приложения.