nginx

На нескольких администрируемых серверах, постоянно сталкиваюсь с ddos атаками на http. Не открою великую тайну, сказав что от хорошей ddos атаки на сервере закрыться практически не реально, забьют канал и привет, далее либо ssh не доступен, либо хостер блокирует сервер за превышение трафика ( прецеденты были ). Однако минимизировать вред от небольшой атаки на сайт вполне возможно и на сервере. В данном материале рассмотрим использование geoip модуля nginx для защиты от ddos атак.

Думаю многие играли или играют или хотя-бы слышали о такой популярной игрухе как Counter Strike. Серверов с этой игрой в сети как грязи нынче.
В общем случилось поднимать игровой сервак + веб морду для модуля статистики Server Stat System.

По работе, периодически приходиться заниматься переносом уже работающих ресурсов с веб сервера Apache на связку nginx - fastcgi, или со старого сервера на новый с уже установленным веб сервером nginx. Ни в коем разе не допускаю мысли, что Apache плохой веб сервер, учитывая количество модулей, он очень универсален, можно решать практически любые задачи, но его монстрообразность предъявляет определенные требования к ресурсам системы.

Итак, имеем веб сервер Nginx в качестве фронтэнда, на бакэндах Apache и какой-нибудь fastcgi (spawn-fcgi или php-fpm). Функциональные возможности серверов, nginx и apache, несколько различаются, и одно из различий как раз в том, что nginx не поддерживает обработку файлов htaccess, которые в apache используются практически повсеместно. Большинство сайтовых движков (CMS), поддерживают возможность генерировать так называемые ЧПУ(человекопонятный урл, в оригинале, SEF - search engines friendly url), но для этого, веб сервер, должен обрабатывать строку запроса определенным образом, что apache и делает с помощью mod_rewrite и правил в файле .htaccess. Задача: заменить правила .htaccess, соответствующими директивами в конфигурационном файле nginx.conf.

301 Moved Permanently, редирект, говорящий что ресурс перемещен на постоянной основе. В интернетах пишут что мол типа архинеобходимо для SEO, мол поисковики это дюже уважают), спорить не буду, не вникал. В веб сервере Nginx 301 редирект настраивается в конфигурационном файле ( в apache можно через файл .htaccess ), таким образом:

Контролируемое скачивание, реализуемое в веб сервере Nginx с использованием заголовка X-Accel-Redirect, подразумевает следующий алгоритм при отдаче контента:

• Клиент нажимает на ссылку "скачать файл"
• Запрос передается веб серверу Nginx
• Nginx в свою очередь передает запрос некоему скрипту на проверку
• Скрипт, после проверки, например валидности запроса на скачивание, возвращает запрос в Nginx, устанавливая заголовок X-Accel-Redirect
• Запрос с заголовком X-Accel-Redirect попадает в специальный внутренний location, сервера Nginx, откуда и отдается клиенту

Код состояния HTTP - это часть строки заголовка, ответа веб сервера на запрос клиента, информирующая о результате запроса и о том, что клиент должен предпринять далее. Думаю не все знают как выглядит заголовок ответа сервера, зато уверен, каждый, пользующийся интернетом, не раз сталкивались, со страницей 404 Not Found или 403 Forbadden. Это и есть, видимый пользователю результат, выдачи сервером, того или иного кода статуса в строке заголовке.

Балансировка нагрузки и отказоустойчивость Nginx, реализуется с помощью специального модуля ngx_http_upstream. Директива upstream позволяют организовывать группы серверов ( upstream ), распределяя между ними запросы для проксирования в директивах proxy_pass и fastcgi_pass. Кроме того, это дает Nginx возможность, реагировать на нештатные ситуации в апстриме, например, в случае выхода из строя одного или нескольких серверов из группы, запрос будет отправлен на следующий, работающий сервер апстрима.

В предыдущей статье "Установка и настройка веб сервера Nginx в качестве проксирующего фронтэнда к Apache", был рассмотрен простой вариант установки и использования Nginx, с настройками по-умолчанию, в качестве проксирующего сервера, с сервером Apache в качестве проксиркемого бакэнда.

В данном материале хотелось-бы рассказать о более сложном варианте установки и настройки Nginx, для построения связки Nginx Apache FastCGI. Для организации FastCGI сервера, будет использована утилиты, spawn-fcgi, ранее входившая в состав веб сервера lighttpd, а теперь выделенная в отдельный порт.

В предыдущей статье, "Веб сервер Nginx, обзор функциональных возможностей", речь шла об основных функциональных возможностях сервера Nginx, а так-же затронут вопрос его использования в качестве проксирующего фронтенд-сервера в связке с веб сервером Apache. Здесь хотелось-бы рассказать о практической стороне вопроса, то есть перейти непосредственно к установке и настройке вышеупомянутой связки, Nginx - Apache. Так как всем остальным *nix системам, я предпочитаю FreeBSD, на ней и будем все это поднимать.

Nginx - небольшой по размерам, очень быстрый, достаточно функциональный веб сервер и почтовый прокси-сервер, разработчик Игорь Сысоев ( rambler.ru ). Из-за очень маленького потребления ресурсов системы и скорости работы, а так-же гибкости конфигурирования, веб сервер Nginx часто используется в качестве фронтэнда к более тяжеловесным серверам, такими как Apache, в проектах с высокой нагрузкой. Классическим вариантом является связка, Nginx - Apache - FastCGI. Работая в такой схеме, сервер Nginx, принимает все запросы приходящие по HTTP, и в зависимости от конфигурации и собственно самого запроса, решает, обработать-ли запрос самому и отдать клиенту готовый ответ или отправить запрос на обработку, одному из бакэндов ( Apache или FastCGI ).