Nginx, веб-сервер с открытым исходным кодом, относительно новый на рынке, в последнее время вызывает некоторый интерес, за последние годы показав очень хорошие результаты в некоторых тестах.
Выбирая серверное программное обеспечение для общедоступных бизнес-приложений, я задавался вопросом, не будет ли безответственно с точки зрения безопасности использовать серверное программное обеспечение, которое может отсутствовать повсеместно, например Nginx.
На другом конце спектра находится Apache с годами общественного контроля, многочисленными исправленными уязвимостями и командой безопасности.
Вот мои мысли о преимуществах двух моих серверов-кандидатов, которые сильно различаются по доле рынка, сообществам и общей среде разработки.
Вездесущность. Мне кажется, что сочетание непростой цели и мелкого игрока помогло некоторым программным продуктам стать менее вероятными жертвами целевых атак. Хорошим примером этого могут быть платформы Apple Mac OS X, в которых в недавнем прошлом было относительно мало попыток по сравнению с Window.
Доля рынка серверов Netcraft за июнь 2009 г. предполагают, что конкуренты занимают 4% и 50% рынка Nginx и Apache соответственно.
Меньшая кодовая база, меньше ошибок. Это всего лишь гипотеза; Я не просматривал ни одну из кодовых баз, но, предполагая аналогичное соотношение кода и ошибок, меньшая кодовая база может привести к меньшему количеству эксплойтов.
Размер кодовой базы, по словам Олоха, составляет 635: 75, причем больший размер - Apache. Я не уверен, включают ли это модули, но, учитывая огромную дельту, вероятно, включает. (Это, конечно, привело бы к очень неверному выводу, поскольку, если ваша цель - безопасность, вы будете запускать только те модули, которые вам нужны.)
Зрелость. Как я уже упоминал ранее, проект прошел через множество эксплойтов и пристальное внимание общественности.
Это может привести к несколько меньшему риску эксплойтов нулевого дня, потому что вероятность того, что зияющие проблемы будут упущены, будет ниже. Это также может означать, что новые эксплойты будут менее критичными.
Быстрый поиск не показал, подвергался ли Apache аудиту безопасности.
Вездесущность кажется палкой о двух концах. Независимо от того, является ли повсеместность в целом хорошей или плохой, может не быть линейной зависимости (и, вероятно, включает в себя другие факторы, например, насколько вы чрезвычайно уязвимы для эксплойтов). Я очень сомневаюсь, что есть исследования о влиянии повсеместности на уязвимости безопасности, хотя я, надо признать, пробовал искать.
Я, вероятно, не стал бы задумываться об этом, если бы мы говорили о социальном приложении, новостном сайте или медиа, работающих на сервере, отделенном от бизнес-приложения. Для приложения, которое имеет дело с платежами, личной информацией и номерами кредитных карт, моя текущая информация склоняется к Apache.
Поскольку я не эксперт по безопасности, и мои мысли не были собраны с научной точки зрения и поэтому могут быть не слишком убедительными, я был бы признателен за любые комментарии о том, какие факторы должны влиять на такое решение. По крайней мере, это остается для рассмотрения другими в том же положении.
nginx обслуживает пару процентов от мирового числа веб-сайтов, так что это далеко не так уж мало. Это сотни тысяч, если не миллионы сайтов, и поэтому nginx достаточно велик, чтобы стать достойной целью для эксплойтов.
У nginx уже были проблемы с безопасностью, и сообщество разработчиков открытого кода сообщило об уязвимостях автору, который их исправил. Найдите «безопасность» в журналах изменений, и вы увидите, что есть рабочий процесс: http://nginx.net/CHANGES-0.6
Таким образом, nginx имеет почти тот же процесс, что и Apache, для устранения проблем с безопасностью. Это может быть меньшая команда и менее формализованная, но она работает примерно так же.
Наличие небольшой, плотной кодовой базы с чистой и простой архитектурой - серьезное улучшение с точки зрения безопасности. Меньше кода = статистически меньше ошибок. Опыт показывает, что по мере увеличения базы кода количество ошибок растет более чем линейно. Предполагая аналогичное соотношение кода и ошибок, меньшая кодовая база воля привести к меньшему количеству эксплойтов.
Было бы безответственно с точки зрения безопасности перейти на nginx из-за его меньшей пользовательской базы? Я бы ответил абсолютно нет, nginx - очень хороший выбор, также для безопасности.
Однако я бы предложил взглянуть на безопасность HTTP-сервера несколько иначе. Существует проблема переполнения буфера в http deamon, что может привести к эксплойту против самого http deamon. Для большинства проектов влияние этого можно довольно легко минимизировать, используя инструменты уровня ОС, такие как jails / croot / virtualization, для «контейнеризации» http deamon и ограничения эффекта успешной атаки.
Атака на веб-приложение может быть хуже и более распространена, особенно для веб-приложений собственной разработки, безопасность которых часто не проверялась экспертами. Примеры включают использование кросс-сторонних сценариев или SQL-инъекций для злонамеренных действий с пользовательскими данными, снятия денег, кражи базы данных имен пользователей и паролей и т. Д.
У Apache есть одно важное преимущество в области безопасности веб-приложений - это сторонний модуль mod_security. Думайте об этом как о гигантском механизме регулярных выражений для HTTP-запросов, который позволяет вам выполнять сопоставление с образцом и фильтрацию в любой части HTTP-вызова. Это можно использовать, чтобы значительно уменьшить поверхность атаки на ваш собственный код веб-приложения.
Для стека веб-приложений с открытым исходным кодом, ориентированного на безопасность, я мог бы использовать:
Вы также можете сделать это наоборот - Apache с mod_security, выполняющий балансировку нагрузки перед веб-серверами nginx. В значительной степени вопрос заключается в том, где должна быть нагрузка на ЦП - HTTP-фильтрация с помощью mod_security требует значительного количества ресурсов ЦП, поэтому балансировщик нагрузки Apache с mod_security может обрабатывать не больше, чем несколько внутренних веб-серверов. Перегрузка балансировщика нагрузки значительно снижается, если балансировщик нагрузки представляет собой небольшой и быстрый экземпляр nginx, а веб-серверы выполняют свою собственную фильтрацию mod_security.
Это дает вам контейнерный HTTP-прокси в качестве уровня косвенного обращения между общедоступным Интернетом и вашим веб-приложением, а также mod_security в качестве масштабируемого межсетевого экрана уровня HTTP перед кодом вашего веб-приложения. Но будьте готовы к тому, что это, особенно mod_security, потребует много времени на настройку и полноценную работу без нежелательных побочных эффектов.
Незаметность как модель безопасности - не основа для хорошей ИТ.
Однако это не означает, что Nginx - не лучшее решение для вас. Приложение - всего лишь одна точка безопасности.
Сам не проводя исследования, я не могу сказать, что преимущества больше в пользу Apache, но, глядя на ваш список, аргументы в пользу Nginx слабые.
Одна вещь против nginx заключается в том, что текущая версия в Ubuntu 10.04 LTS все еще находится на уровне .7, тогда как основной nginx находится на уровне .8 и повторяется в сторону .9. Apache, похоже, лучше поддерживается с точки зрения обновлений в официальных пакетах Ubuntu LTS. Как одному человеку, управляющему 7 серверами в небольшой организации и другим задачам, очень сложно документировать все нестандартные установки программного обеспечения и поддерживать их в актуальном состоянии. Поэтому мы придерживаемся того, что есть в дистрибутиве LTS, и просто обновляем сервер, используя стандартные меры.
Я столкнулся с этим же вопросом некоторое время назад, когда работал с Sun Web Server. Это сервер NSAPI, хотя он также имеет контейнер Java. Ядро сервера с открытым исходным кодом и бесплатно. Он известен своей безопасностью. Он имеет простой интерфейс для администрирования и надежен. На самом деле это старый сервер Fastrack Netscape.