Сегодня рассмотрим настройку виртуального хоста, обслуживающего сайт со статическим контентом. То бишь, никаких CGI, Perl, PHP и еже с ними. Все примеры, упоминающиеся в статье, относятся и проверялись на Debian Linux 5.0 Lenny . Владельцев других систем это никак не должно смущать, поскольку меняться могут только пути к файлам конфигурации, в то время как их содержимое применимо к любой системе, на которой работает Nginx.
Способ хранения файлов конфигурации
Как вы можете помнить из предыдущей статьи, в файлах конфигурации Nginx можно использовать директиву include , которая умеет включать в в основной файл конфигурации содержимое других файлов. Такой подход снабжает администраторов дополнительной гибкостью конфигурирования сервера, что зачастую экономит время и силы.
Если вы обратили внимание, в основном файле конфигурации /etc/nginx/nginx.conf нет ни слова о конфигурации виртуальных серверов. Совсем ничего не сказано о том, где находится корень документов сервера, на каком порту сервер должен ожидать входящих соединений и прочее. Однако предпоследней строкой в файле конфигурации записано следующее:
Include /etc/nginx/sites-enabled/*;
То есть, из каталога /etc/nginx/sites-enabled считывается содержимое всех файлов и применяется к текущей конфигурации сервера. Заглянув в упомянутый каталог, вы увидите там один файл default , являющийся символической ссылкой на файл /etc/nginx/sites-available/default . Тоже очень удобный подход: вам вдруг понадобилось отключить какой-то виртуальный хост, вы просто удаляете символическую ссылку, а на заморачиваетесь с перемещением файла туда-сюда.
Создание виртуального сервера
Для «чистоты эксперимента» предлагаю удалить поставляемую с дистрибутивом символическую ссылку /etc/nginx/sites-enabled/default и начать, так сказать, с чистого листа.
Создайте файл /etc/nginx/sites-available/myvhost со следующим содержимым:
Server { listen 80; server_name myvhost; access_log /var/log/nginx/myvhost.log; location / { root /var/www/myvhost/; index index.htm index.html; autoindex on; } }
Это и есть сама простая конфигурация виртуального сервера в Nginx. Теперь об используемых параметрах по порядку.
Первая опция server , за которой следует фигурная скобка, начинает новую секцию. Именно в секциях server и описываются конфигурации всех виртуальных серверов в Nginx.
Опцией listen мы сообщаем Nginx номер порта, на котором наш виртуальный сервер должен ожидать соединений. По умолчанию значение этой опции равно 80 , и в приведённом примере значение определено лишь для наглядности. Также при помощи этой опции можно указать не только номер порта, но и адрес сетевого интерфейса, к которому нужно «прицепить» данный сервер. Например следующие два примера «вешают» сервер на все доступные в системе TCP/IP-интерфейсы, на порт 8080:
Listen 8080 listen *:8080
Следующий пример связывает виртуальный сервер с определённым сетевым интерфейсом с IP-адресом 192.168.0.1, ожидая входящих соединений на порту 8080:
Listen 192.168.0.1:8080
Опция server_name определяет имя виртуального сервера, которое используется при анализе веб-сервером HTTP-заголовка Host , приходящего от клиента. Именно эта опция и реализует настройку виртуальных хостов, базирующихся на имени. Например, вот так будет выглядеть фрагмент конфигурации двух виртуальных хостов на одном сервере:
Server { ... listen 80; server_name example-1.com ... } server { ... listen 80; server_name example-2.com ... }
Параметров у опции server_name может быть более одного, таким образом вы можете определить псевдонимы вашего сервера, например:
Server_name example-1.com www.example-1.com www1.example-1.com
Также, можно использовать символ звёздочки, заменяющий любую последовательность символов в имени сервера:
Server_name example-1.com *.example-1.com
С параметром access_log мы знакомились в . Значение этого параметра определяет месторасположение и формат лог-файла доступа к контенту сервера.
Опция location заслуживает рассмотрения в отдельной заметке, поэтому в данной статье мы коснёмся её значения и возможностей лишь слегка, в объёме достаточном для конфигурирования статического веб-сервера. Использование опции location позволяет вам настраивать поведение сервера в зависимости от значения URI, полученного от клиента. Таким образом, секция server может содержать несколько вложенных секций location, описывающих конфигурацию на основе части URI. В примере, приведённом в начале статьи определён всего один location, которому будет соответствовать любой URI, полученный от клиента, поскольку любой URI содержит символ прямого слэша.
Например, если вам необходимо, чтобы при обнаружении в URI подстроки /images/ , Nginx не обращался в корневой каталог сервера, а искал файлы в каталоге /mnt/server2/var/www/images/ , можно определить следующие два location:
Location / { root /var/www/myvhost/; } location /images/ { root /mnt/server2/var/www/; }
В приведённых выше примерах использования location используется поиск подстроки в строке URI. То есть, подстрока /images/ будет найдена как в http://server/images /, так и http://server/my/images /. Если вам необходимо, чтобы Nginx выполнял поиск точного соответствия, для этого можно воспользоваться символом "=" , который и заставляет сервер вести поиск таким образом:
Location = /images/ { root /mnt/server2/var/www/; }
Также вы можете определить подстроку, с которой должен начинаться URI. Для этого используется конструкция из двух символов "^~" :
Location ^~ /images/ { ... }
Ну и регулярные выражения, само-собой, поддерживаются и дают большую гибкость при описании location. Следующий location будет соответствовать всем URI, содержащим в конце имена графических файлов (без учёта регистра):
Location ~* \.(gif|jpg|jpeg)$ { ... }
То же самое, но с учётом регистра:
Location ~ \.(gif|jpg|jpeg)$ { ... }
И немного о порядке очереди обработки опций location в Nginx. Вопреки тому, что многим кажется на первый взгляд, совершенно не имеет значения (кроме регулярных выражений, само-собой) в каком порядке определены location в конфигурационном файле. Как ни меняйте их местами, результат будет один и тот же. При поиске нужного локейшена, Nginx следует следующему алгоритму:
- Выполняется поиск правила, начинающегося с "=" . Как только такое правило будет найдено, дальнейший поиск будет прекращён.
- Выполняется поиск «обычных» правил, т. е. не регулярных выражений. Если среди них будет найдено правило, начинающееся с "^~" , дальнейший поиск будет прекращён.
- Обрабатываются регулярные выражения в том порядке, в котором они встречаются в файле конфигурации.
- Если будет найдено соответствие по п. 3, то будет использоваться именно этот location, в противном случае будет использоваться location, найденный в п. 2.
Опция root своим значением определяет путь к корню документов виртуального сервера на файловой системе.
При помощи опции index вы можете определить имена файлов индексных документов, которые будет «отдавать» клиентам Nginx, если был запрошен доступ к каталогу. Если в каталоге такого файла не окажется и для данного location отключена опция autoindex , то клиент в ответ получит HTTP-код 403 , говорящий о том, что доступ запрещён.
Опция autoindex настраивает поведение Nginx в случае, если в каталоге не найден запрашиваемый индексный файл. Если значением опции autoindex, как примере выше, является "on" , то сервер вернёт клиенту содержимое каталога в виде HTML-списка файлов. По умолчанию autoindex отключён, и будьте осторожны с ней, чтобы ненароком не вывесить на всеобщее обозрение критически-важную информацию.
Перезапуск сервера
Теперь, когда конфигурационный файл готов, необходимо сделать на него символическую ссылку из каталога /etc/nginx/sites-enabled/ , чтобы при перезапуске Nginx подключил его содержимое в свою конфигурацию:
# ln -s /etc/nginx/sites-available/myvhost /etc/nginx/sites-enabled/myvhost
# mkdir /var/www/myvhost
Осталось перезапустить сервер:
# /etc/init.d/nginx restart
И, если все настройки были выполнены без ошибок, вы сможете подключиться к вашему первому виртуальному серверу Nginx при помощи веб-браузера и увидеть пустой индекс файлов корневого каталога сервера. Попробуйте разместить пару статических html-файлов в каталоге /var/www/myshost и затем получить доступ к ним из вашего браузера.
В следующей статье мы рассмотрим конфигурацию SSL-сервера в Nginx.
Более 50% трафика во всем мире обслуживает технология связки Apache и Nginx – веб сервера, которые имеют открытый исходный код. Nginx исполняет функцию фронтэнда, Apache – бэкэнда . Nginx первым принимает запросы пользователей и выдает по ним необходимый контент – изображения, файлы, скрипты. Тяжелый Apache в свою очередь не имеет с этим дело, а обрабатывает динамику. Nginx проксирует запросы и возвращает ответы . Данная связка отлично подходит для больших сайтов, которые посещают много пользователей. Для маленьких сайтов данная связка не даст роста производительности. Apache и Nginx снижает нагрузку на сервер в общем, благодаря тому, что Nginx обрабатывает статический контент, а Apache динамический.
Apache и Nginx не нужно рассматривать как взаимозаменяемые технологии, не смотря и на то, что они имеют множество схожих функций. Каждый из веб серверов имеет свои достоинства и его применение зависит от поставленной задачи. В данной статье рассмотрим каждую технологию в зависимости от сферы применения. Статья будет полезна собственникам виртуального и выделенного физического сервера.
Функциональный и быстрый Nginx был выпущен в 2004 году и после этого релиза начал набирать свою популярность. Благодаря своей легкости и масштабируемости хорошо работает на любом оборудовании. Nginx используют в двух направлениях: как веб сервер или как прокси.
Что делает Nginx в качестве веб сервера?
- автоматически создает кэш дескрипторы и списки файлов, обслуживает индексные файлы и статические запросы;
- ускоряет отказоустойчивость, проксирование и рапределение нагрузки;
- кэширует при FastCGI и ускоряет проксирование;
- поддерживает SSL;
- поддерживает Perl;
- имеет филтры и модульность;
- аунтифецирует HTTP и фильтрирует SSL.
В качестве прокси Nginx:
- полное обеспечение StartTLS и SSL;
- легкость аутентификации (USER/PASS, LOGIN);
- использует внешний HTTP-сервер для перенаправления на POP3/IMAP-бэкенд.
Как видим, Nginx выполняет множество функций, при этом не перегружая систему. По официальным данным, технологию используют более 56 млн. сайтов во всем мире (к примеру, Rambler, Yandex, Mail, Begun, WordPress.com, vk.com, Facebook, Rutracker.org), но по популярности Nginx уступает Apache. Почему же так популярен Apache?
Веб сервер Apache – кросплатформенное программное обеспечение, которое было создано в 1995 году. Благодаря большой документации и хорошей интеграции с сторонним ПО, Apache получил огромное распространение. Поддерживает следущие ОС – Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS. .
Преимущества веб сервера Apache:
- поддержка языков программирования PHP, Python, Ruby, Perl, ASP, Tcl ;
- легкость в подключении внешних модулей;
- поддержка технологий CGI и FastCGI ;
- наличие механизмов, которые обеспечивают безопасноть и разграничение к доступу данных;
- возможность использовать СУБД для аутентификации пользователей;
- гибкая и надежная конфигурация системы;
- подходит для приложений, которым нужна мощная криптографическая защита данных ;
- возможность создания пользовательских директорий для веб-сайта;
- возможность настройки виртуальных хостов , с помощью которых на одном физическом сервере можно создать несколько виртуальных;
- ведет протоколы того, что происходит на вашем сервере;
- активная обратная связь с разработчиками и своевременное решения возникших ошибок в ПО.
Но несмотря на все достоинства веб-сервера Apache несколько тяжелый в настройке и работе, поэтому не каждый новичок сможет с ним справиться. Но если ваш проект нуждается именно в этом ПО, тогда вы сделаете правильный выбор в пользу Apache.
Хотите обезопасить работу PHP на сервере? Об этом более подробно .
После ознакомления с плюсами и минусами Apache и Nginx, Вы можете выбрать полезное решения для своего сайта в зависимости от целей, которые преследуете. Но возможно Вам понадобится именно связка Apache+Nginx для достижения наилучшего результата. Например, часто используют Nginx перед Apache в качестве реверс прокси. Такая комбинация позволяет обрабатывать много конкурентных запросов и сортирует их. Те запросы, которые не под силу Nginx отправляются к Apache, тем самым снижается нагрузка на последний. Отказоустойчивость в таком случае увеличивается. Перед выбором веб сервера нужно провести обязательные тесты на производительность и возможности каждого решения.
Обо всех технологиях, которые поддерживает хостинг HyperHost, более подробно по .
Данная статья была предоставлена для общего ознакомления с возможностями связки веб серверов Apache и Nginx. Еще больше информации в .
Если понадобится наша помощь, обращайтесь!
Мы будем рады ответить на все интересующие вас вопросы по настройке веб серверов. Также у нас Вы всегда можете с бесплатным администрированием. Вся ли техническая поддержка хостеров одинакова? Об особенностях бесплатного и платного администрирования в специальной .
17249 раз(а) 10 Сегодня просмотрено раз(а)
Выделенный Web-сервер на основе nginx – отличный способ повышения производительности Web-сайтов. В скорости обработки статического контента ему просто нет равных: он легко выдерживает несколько тысяч одновременных соединений и может быть легко оптимизирован и подогнан под любую конфигурацию. Однако? выступая в качестве фронт-энда для Apache, nginx оказывается наиболее уязвимым местом всей Web-инфраструктуры, поэтому безопасности nginx необходимо уделить особое внимание.
Эта статья – своего рода ликбез, или, если хочешь, резюме всех техник повышения безопасности nginx. В ней не будет теории, описания основ настройки Web-сервера и прочей воды. Вместо этого ты получишь исчерпывающий практический материал, описывающий все основные шаги, которые необходимо проделать для того, чтобы получить по-настоящему защищенный Web-сервер.
Установка
Пакет nginx доступен в прекомпилированном виде для любого дистрибутива. Однако собрав сервер самостоятельно, ты сможешь сделать его более компактным и надежным, а также получишь возможность изменить строку приветствия Web-сервера, чтобы отбить несмышленых скрипт-кидди.
Измени строку приветствия Web-сервера
Скачай исходники nginx, открой файл src/http/ngx_http_header_filter_module.c и найди следующие две строки:
static char ngx_http_server_string = "Server: nginx" CRLF;
static char ngx_http_server_full_string = "Server: " NGINX_VER CRLF;
Замени их на что-то вроде этого:
static char ngx_http_server_string = "Server: ][ Web Server" CRLF;
static char ngx_http_server_full_string = "Server: ][ Web Server" CRLF;
Удали все неиспользуемые тобой nginx-модули
Некоторая часть модулей nginx подключается к Web-серверу прямо во время компиляции, и любой из них таит в себе потенциальную опасность. Возможно, в будущем в одном из них будет найдена уязвимость, и твой сервер окажется под угрозой. Отключив ненужные модули, ты сможешь значительно снизить риск возникновения такой ситуации.
Выполни сборку с помощью следующих команд:
# ./configure --without-http_autoindex_module --without-http_ssi_module
# make
# make install
Так ты получишь nginx с заранее отключенными (и в большинстве случаев бесполезными) модулями SSI (Server Side Includes) и Autoindex. Чтобы узнать, какие модули можно безболезненно выбросить из Web-сервера, запусти скрипт configure с флагом ‘-help’.
Препарируем nginx.conf
После установки nginx следует настроить. На страницах журнала уже был материал, описывающий этот процесс, мы же будем придерживаться темы статьи и поговорим о способах повышения безопасности сервера.
Отключи показ версии сервера на всех ошибочных страницах
Добавь в файл nginx.conf строку “server_tokens off”. Это заставит nginx скрывать информацию о типе и версии Web-сервера на страницах, генерируемых в ответ на ошибочный запрос клиента.
Настрой защиту от срыва стека
Добавь в секцию server следующие строки:
# vi /etc/nginx/nginx.conf
# Максимальный размер буфера для хранения тела запроса клиента
client_body_buffer_size 1K;
# Максимальный размер буфера для хранения заголовков запроса клиента
client_header_buffer_size 1k;
# Максимальный размер тела запроса клиента, прописанный в поле Content-Length заголовка. Если сервер должен поддерживать загрузку файлов, это значение необходимо увеличить
client_max_body_size 1k;
# Количество и размер буферов для чтения большого заголовка запроса клиента
large_client_header_buffers 2 1k;
Обрати внимание на директиву large_client_header_buffers. По умолчанию, для хранения строки URI nginx выделяет четыре буфера, размер каждого из которых равен размеру страницы памяти (для x86 это 4 Кб). Буферы освобождаются каждый раз, когда по окончанию обработки запроса соединение переходит в состояние keep-alive. Два буфера по 1 Кб могут хранить URI длиной только 2 Кб, что позволяет бороться с ботами и DoS-атаками.
Для повышения производительности добавь следующие строки:
# vi /etc/nginx/nginx.conf
# Таймаут при чтении тела запроса клиента
client_body_timeout 10;
# Таймаут при чтении заголовка запроса клиента
client_header_timeout 10;
# Таймаут, по истечению которого keep-alive соединение с клиентом не будет закрыто со стороны сервера
keepalive_timeout 5 5;
# Таймаут при передаче ответа клиенту
send_timeout 10;
Контролируй количество одновременных соединений
Для защиты Web-сервера от перегрузки и попыток осуществить DoS-атаку добавь в конфиг следующие строки:
# vi /etc/nginx/nginx.conf
# Описываем зону (slimits), в которой будут храниться состояния сессий. Зона размером 1 Мб может хранить около 32000 состояний, мы устанавливаем ее размер равным 5 Мб
limit_zone slimits $binary_remote_addr 5m;
# Задаем максимальное количество одновременных соединений для одной сессии. По сути, это число задает максимальное количество соединений с одного IP
limit_conn slimits 5;
Первая директива должна находиться в секции HTTP, вторая – в секции location. Когда количество соединений выйдет за пределы лимитов, клиент получит сообщение «Service unavailable» с кодом 503.
Разреши коннекты только к своему домену
Взломщики могут использовать ботов для сканирования подсетей и поиска уязвимых Web-серверов. Обычно боты просто перебирают диапазоны IP-адресов в поисках открытых 80 портов и посылают запрос HEAD для получения информации о веб-сервере (или главной странице). Ты можешь легко предотвратить такой скан, запретив обращение к серверу по IP-адресу (добавить в подсекцию location):
# vi /etc/nginx/nginx.conf
if ($host !~ ^(host.com|www.host.com)$) {
return 444;
}
Ограничь количество доступных методов обращения к Web-серверу
Некоторые боты используют различные методы обращения к серверу для попытки определения его типа и/или проникновения, однако в документе RFC 2616 четко сказано, что Web-сервер не обязан реализовывать их все, и неподдерживаемые методы могут просто не обрабатываться. Сегодня используемыми остаются только методы GET (запрос документа), HEAD (запрос заголовков сервера) и POST (запрос на публикацию документа), поэтому все остальные можно безболезненно отключить с помощью помещения следующих строк в секцию server конфигурационного файла:
# vi /etc/nginx/nginx.conf
if ($request_method !~ ^(GET|HEAD|POST)$) {
return 444;
}
Отшивай ботов
Другой способ блокирования ботов, сканеров и прочей нечисти основан на определении типа клиента (user-agent). Он не слишком эффективен, потому как большинство ботов косят под вполне легитимные браузеры, но в ряде случаев остается полезным:
# vi /etc/nginx/nginx.conf
# Блокируем менеджеры загрузки
if ($http_user_agent ~* LWP::Simple|BBBike|wget) {
return 403;
}
# Блокируем некоторые типы ботов
if ($http_user_agent ~* msnbot|scrapbot) {
return 403;
}
Блокируй Referrer-спам
Если твой сайт публикует Web-логи в общедоступном виде, ты легко можешь стать жертвой Referrer-спама (когда спам-боты обращаются к твоему серверу, указывая в заголовке referrer – адрес рекламируемого сайта). Такой вид спама может легко испортить SEO-рейтинги интернет-страницы, поэтому его необходимо блокировать в обязательном порядке. Один из способов сделать это – занести наиболее частые слова, встречающиеся в адресах рекламируемых сайтов, в черный список.
# vi /etc/nginx/nginx.conf
# Секция server
if ($http_referer ~* (babes|forsale|girl|jewelry|love|nudit|organic|poker|porn|sex|teen))
{
return 403;
}
Блокируй хотлинк
Хотлинк – это включение в страницу изображения (или иного контента) с другого сайта. По сути, это воровство, потому как изображение, на которое ты потратил не один час своего свободного времени, не только свободно используется другими, но и создает нагрузку на твой Web-сервер, не приводя на него посетителей. Для борьбы с хотлинками достаточно сделать так, чтобы изображения отдавались клиенту только в том случае, если он запросил их, уже находясь на сайте (другими словами, заголовок referrer-запроса должен содержать имя твоего сайта). Добавь в секцию server конфигурационного файла nginx.conf следующие строки (host.com – это адрес твоего сайта):
# vi /etc/nginx/nginx.conf
location /images/ {
valid_referers none blocked www.host.com host.com;
if ($invalid_referer) {
return 403;
}
}
В качестве альтернативы ты можешь настроить сервер на отдачу специального баннера с сообщением о воровстве вместо запрашиваемого изображения. Для этого замени строку «return 403» на строку:
rewrite ^/images/uploads.*\.(gif|jpg|jpeg|png)$ http://www.host.com/banned.jpg last
Защищай важные каталоги от посторонних
Как и любой другой Web-сервер, nginx позволяет регулировать доступ к каталогам на основе IP-адресов и паролей. Эту возможность можно использовать для закрытия некоторых частей сайта от посторонних глаз. Например, для отрезания URI от внешнего мира:
# vi /etc/nginx/nginx.conf
location /uploads/ {
# Разрешаем доступ только машинам локальной сети
allow 192.168.1.0/24;
# Отшиваем всех остальных
deny all;
}
Теперь к документам каталога uploads будут иметь доступ только пользователи локальной сети. Для установки пароля придется проделать более сложные действия. Сначала необходимо создать приватный для nginx-файл паролей и добавить в него необходимых пользователей (в качестве примера добавим пользователя admin):
# mkdir /etc/nginx/.htpasswd
# htpasswd -c /etc/nginx/.htpasswd/passwd admin
# vi /etc/nginx/nginx.conf
location /admin/ {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd/passwd;
}
Новых пользователей можно добавить с помощью следующей команды:
# htpasswd -s /etc/nginx/.htpasswd/passwd пользователь
Используй SSL
Если твой сайт работает с приватными данными пользователей, такими как номера кредитных карт, пароли от других сервисов, или же предоставляет доступ к другой важной информации, которая может стать лакомым кусочком для третьих лиц, позаботься о шифровании. Nginx хорошо работает с SSL, и этой возможностью нельзя пренебрегать.
Для настройки SSL-шифрования средствами nginx достаточно выполнить несколько простых шагов. Сначала ты должен создать сертификат с помощью следующей последовательности команд:
# cd /etc/nginx
# openssl genrsa -des3 -out server.key 1024
# openssl req -new -key server.key -out server.csr
# cp server.key server.key.org
# openssl rsa -in server.key.org -out server.key
# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Затем описать сертификат в конфигурационном файле nginx:
# vi /etc/nginx/nginx.conf
server {
server_name host.com;
listen 443;
ssl on;
ssl_certificate /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key;
access_log /etc/nginx/logs/ssl.access.log;
error_log /etc/nginx/logs/ssl.error.log;
}
После этого можно перезагрузить Web-сервер:
# /etc/init.d/nginx reload
Естественно, без поддержки со стороны самого Web-сайта это делать бессмысленно.
Другие способы
Установи правильные значения системных переменных
Открой файл /etc/sysctl.conf и помести в него следующие строки:
# vi /etc/sysctl.conf
# Защита от smurf-атак
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Защита от неправильных ICMP-сообщений
net.ipv4.icmp_ignore_bogus_error_responses = 1
# Защита от SYN-флуда
net.ipv4.tcp_syncookies = 1
# Запрещаем маршрутизацию от источника
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Защита от спуфинга
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Мы не маршрутизатор
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Включаем ExecShield
kernel.exec-shield = 1
kernel.randomize_va_space = 1
# Расширяем диапазон доступных портов
net.ipv4.ip_local_port_range = 2000 65000
# Увеличиваем максимальный размер TCP-буферов
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling = 1
Размести корневой каталог Web-сервера на выделенном разделе
Поместив корневой каталог Web-сервера в выделенный раздел и запретив на нем размещение любых исполняемых файлов и файлов-устройств, ты обезопасишь остальную часть системы от тех, кто сможет получить доступ к корню Web-сервера. При этом запись в файле /etc/fstab должна иметь примерно такой вид:
/dev/sda5 /nginx ext4 defaults,nosuid,noexec,nodev 1 2
Помести nginx в chroot/jail-окружение
Любая современная *nix-система позволяет запереть приложение в изолированной среде исполнения. В Linux для этого можно использовать технологии KVM, Xen, OpenVZ и VServer, во FreeBSD – Jail, в Solaris – Zones. Если ни одна из этих технологий не доступна, ты можешь поместить nginx в классический chroot, который хоть и намного более хрупок, но большинство взломщиков остановить сможет.
Установи правила SELinux для защиты nginx
Хорошей альтернативой изолированным средам исполнения являются локальные системы обнаружения и предотвращения вторжений, такие как SELinux или AppArmor. Будучи правильно настроенными, они смогут предотвратить попытки взлома Web-сервера. По дефолту ни одна из них не настроена для работы в связке с nginx, однако в рамках проекта SELinuxNginx (http://sf.net/projects/selinuxnginx/) были созданы правила для SELinux, которые может использовать любой желающий. Остается только скачать и установить:
# tar -zxvf se-ngix_1_0_10.tar.gz
# cd se-ngix_1_0_10/nginx
# make
# /usr/sbin/semodule -i nginx.pp
Настрой брандмауэр
Обычно nginx устанавливают на выделенных машинах, готовых к высокой нагрузке, поэтому зачастую он остается единственным сетевым сервисом, работающим на сервере. Чтобы обезопасить сервер, достаточно создать совсем небольшой набор правил, которые будут открывать 80, 110 и 143-й порты (если, конечно, nginx должен работать еще и как IMAP/POP3-прокси) и закрывать от внешнего мира все остальное.
Ограничь количество соединений с помощью брандмауэра
Для не слишком нагруженного Web-сайта хорошей идеей будет ограничить количество попыток соединений с одного IP-адреса в минуту. Это сможет уберечь тебя от некоторых типов DoS-атак и брутфорса. В Linux это можно сделать с помощью стандартного iptables/netfilter-модуля state:
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m state --state NEW -m recent --set
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m state --state NEW -m recent --update \
--seconds 60 --hitcount 15 -j DROP
Правила урезают лимит на количество подключений с одного IP в минуту до 15. То же можно сделать и с помощью pf:
# vi /etc/pf.conf
webserver_ip="1.1.1.1"
table
block in quick from
pass in on $ext_if proto tcp to $webserver_ip \
port www flags S/SA keep state \
(max-src-conn 100, max-src-conn-rate 15/60, \
overload
Кроме лимита на количество последовательных подключений (15 в минуту), данное правило устанавливает дополнительный лимит на количество одновременных подключений равный 100.
Настрой PHP
Если ты используешь nginx в связке с PHP, не забудь настроить и его. Вот как должен выглядеть конфигурационный файл /etc/php/php.ini защищенного сервера:
# vi /etc/php/php.ini
# Отключаем опасные функции
disable_functions = phpinfo, system, mail, exec
# Максимальное время исполнения скрипта
max_execution_time = 30
# Максимальное время, которое может потратить скрипт на обработку данных запроса
max_input_time = 60
# Максимальное количество памяти, выделяемое каждому скрипту
memory_limit = 8M
# Максимальный размер данных, отсылаемых скрипту с помощью метода POST
post_max_size = 8M
# Максимальный размер загружаемых файлов
upload_max_filesize = 2M
# Не показывать ошибки PHP-скриптов пользователям
display_errors = Off
# Включаем Safe Mode
safe_mode = On
# Включаем SQL Safe Mode
sql.safe_mode = On
# Позволяем выполнять внешние команды только в этом каталоге
safe_mode_exec_dir = /путь/к/защищенному/каталогу
# Защищаемся от утечки информации о PHP
expose_php = Off
# Ведем логи
log_errors = On
# Запрещаем открытие удаленных файлов
allow_url_fopen = Off
Выводы
Применив описанные в статье рекомендации, ты получишь гораздо более защищенный Web-сервер. Но имей в виду, что не все техники подойдут к твоей конфигурации. Например, защита от брутфорса, основанная на урезании размеров буферов, выделяемых nginx под обработку запросов клиентов, может привести к падению производительности, а в некоторых случаях и к сбоям в обработке запросов. Ограничение на количество подключений нанесет сильный удар по производительности даже средненагруженного Web-сайта, но принесет пользу, если страница имеет низкий поток посетителей. Всегда проверяй, как внесенные тобой изменения повлияли на производительность и общую работоспособность Web-страницы.
О герое дня
Nginx – один самых производительных и популярных Web-серверов в мире. Согласно данным Netcraft, он используется для поддержки более чем 12 миллионов Web-сайтов по всему миру, включая таких мастодонтов как Rambler, Yandex, Begun, WordPress.com , Wrike, vkontakte.ru , megashara.com , Либрусек и Taba.ru. Грамотная архитектура, основанная на мультиплексировании соединений с помощью системных вызовов select, epoll (Linux), kqueue (FreeBSD) и механизме управления памятью на основе пулов (небольших буферов от 1 до 16 Кб), позволяет nginx не проседать даже под очень высокими нагрузками, выдерживая свыше 10000 одновременных соединений (так называемая проблема C10K). Изначально написан Игорем Сысоевым для компании Rambler и открыт в 2004 году под BSD-подобной лицензией.
Вконтакте
Один из самых популярных веб-серверов
Nginx пользуется большой популярностью среди пользователей веб- и прокси-серверов благодаря своей производительности. Сервер имеет много преимуществ, но настроить его будет сложно для новичка. Мы хотим вам помочь разобраться с конфигурационными файлами, синтаксисом, а также настройкой основных параметров Nginx.
Иерархия каталогов
Все конфигурационные файлы сервера располагаются в каталоге /etc/nginx. Кроме того, внутри директории расположены еще несколько папок, а также модульные конфигурационные файлы.
cd /etc/nginx
ls -F
conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/ win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled/
Если вы пользовались Apache, то должны быть знакомы с каталогами sites-enabled и sites-available. Они и определяют конфигурацию сайтов. Созданные файлы хранятся в последнем каталоге. Папка sites-enabled нужна для хранения конфигураций только активированных страниц. Чтобы их связать, нужна символическая ссылка между папками. Конфигурации можно также хранить в каталоге conf.d. При этом, во время запуска Nginx каждый файл с расширением.conf будет читаться по новой. При написании конфигурационных файлов, набирайте код без ошибок и соблюдайте синтаксис. Все остальные файлы располагаются в /etc/nginx. Конфигуратор содержит сведения о конкретных процессах, а также дополнительных компонентах.
Главный конфигурационный файл Nginx - это nginx.conf.
Он считывает все конфигурационные файлы, объединяя их в один, запрашиваемый при запуске сервера. Откройте файл с помощью:
sudo nano /etc/nginx/nginx.conf
На экране появятся вот такие строки:
user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events {
worker_connections 768;
# multi_accept on;
}
http {
. . .
Первая - это общие сведения о Nginx. Фраза user www-data указывает на пользователя, который запускает сервер. Директива pid показывает, где располагаются PID-процессы, предназначенные для внутреннего использования. Строчка worker_processes показывает сколько процессов может одновременно запускать Nginx. Кроме того, здесь можно указать логи (например, лог ошибок определяется за счет директивы error_log). Ниже располагается раздел events. Он нужен для обработки соединений сервера. После него располагается блок http.
Структура конфигурационного файла Nginx
Понимание структуры форматирования файла поможет вам лучше разобраться с конфигурацией веб-сервера. Она делится на структурные блоки. Детали конфигурации блока http разделены на уровни посредством закрытых блоков. Они наследуют свойства из родительского, т.е. того, в котором располагаются. Данный блок хранит большую часть конфигураций сервера. Они делятся на блоки server, внутри которых расположены location.
Когда вы настраиваете сервер Nginx, помните, что чем ниже располагается блок конфигурации, тем меньше элементов будут наследовать свойства и наоборот. В файле присутствует большое количество опций, меняющих работу сервера. Вы можете установить сжатие файлов отправляющихся клиенту, например. Для этого пропишите параметры:
gzip on;
gzip_disable "msie6";
Имейте ввиду, что один и тот же параметр может принимать разные значения в различных блоках. Сначала задайте его вверху, в потом переопределите параметр на нужном уровне. Если последнее действие не выполнить, программа задаст значения в автоматическом режиме.
Последними строками файла nginx.conf выступают:
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
Они свидетельствуют о том, что блоки location и server хранятся вне данного файла. Они определяют настройки url-адресов и конкретных файлов. Такая структура необходима для поддерживания модульной структуры конфигураций. Внутри нее получится создавать новые директории, файлы для различный сайтов. Кроме того, похожие файлы вы сможете сгруппировать. После рассмотрения вы можете закрывать файл nginx.conf.
Виртуальные блоки
Они являются аналогами виртуальных хостов в Apache. Блоки раздела server включают в себя характеристики отдельных сайтов, которые располагаются на сервере. В папке sites-available вы найдете файл блока server, который применяется по умолчанию. Внутри него можно найти вне нужные данные, которые могут потребоваться при обслуживании сайтов.
cd sites-available
sudo nano default
server {
root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / {
try_files $uri $uri/ /index.html;
}
location /doc/ {
alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;
}
}
В вышеуказанном примере было намеренно убрано комментирование. Это было сделано для удобства восприятия. Внутри блоки server располагаются настройки, заключенные в фигурные скобки:
Этот блок размещается с помощью директивы include в конце http, прописанном в файле nginx.conf. Посредством директивы root определяется каталог, где будет располагаться контент сайта. В нем программа и будет искать файлы, которые пользователь будет запрашивать. Путь такой по умолчанию: /usr/share/nginx/www. Nginx отделяет строчки или директивы одна от другой посредством точки с запятой. Если знак препинания не проставить, несколько строчек прочтуться как одна. Чтобы прописать правила, которые будут использоваться в качестве индекса, воспользуйтесь директивой index. Сервер проверит их в порядке перечисления. Если ни одна из имеющихся страничек не была запрошена пользователем, вернется index.html. Если его не будет, то сервер будет искать index.htm.
Правило server_name
Она включает в себя список доменных имен, которые должен будет обработать блок server. Их можно прописать любое количество, разделяя пробелами. Если поставить * в конце или начале домена, удастся задать имя с маской. Звездочка соответствует части имени. Если прописать *.com.ua, то сюда будут относиться все адреса указанной доменной зоны. Если адрес подходит под описание нескольких директив, то он ответит той, которой подходит полностью. При отсутствии совпадений ответ будет на самое длинное имя, у которого есть маска. В противном случае будет выполнено соответствие регулярным выражениям. Имена сервера, которые используют регулярные выражения, начинаются с тильды (~).
Location-блоки
Следующий на очереди у нас будет блок location. Он нужен для определения способа обработки определенных запросов. Если ресурсы не соответствуют никаким иным блокам location, то к ним будут применяться директивы, указанные в скобках. Эти блоки могут включать путь вроде /doc/. Для установления полного соответствия между uri и location, применяется знак =. Применяя тильду, получится задать соответствие регулярным выражениям. Вы также можете установить чувствительность к регистру, поставив ~. Если добавить звездочку, регистр не будет играть никакой роли.
Имейте ввиду: когда запрос будет полностью соответствовать блоку location, он будет использован, а поиск остановится. Когда совпадение неполное, URI будет сравниваться с параметрами директив location. Используется блок с сочетанием ^~, совпадающий с URI для выбора блока. Если данную опцию не задействовать, сервер выбирает оптимальное совпадение, а также произведет поиск с использованием регулярных выражений. Это необходимо для подбора одного из подходящих шаблонов. Если подходящее выражение будет найдено, оно будет использовано. В противном случае, применится предыдущее совпадение с URI. Однако имейте ввиду, что Nginx больше любит полные соответствия. Если их нет, начнется поиск регулярных выражений, а потом по URI. Паритетность поиска задается комбинацией символов ^~.
Правило try_files
Это весьма полезный инструмент, способный проверять наличие файлов в установленном порядке. Он применяет первый соответствующий критериям для обработки запроса. Вы можете использовать дополнительные параметры, чтобы задать, каким образом сервер обслужит запросы. В конфигураторе есть вот такая строка по умолчанию:
try_files $uri $uri/ /index.html;
Что же она означает? Если поступает запрос, который обслуживается блоком location, сервер сначала попытается обработать uri как файл. Это обеспечивает переменная $uri. Когда соответствий ей не будет, uri будет обработан как каталог. Можно проверить его существование, задав слеш в конце: $uri/. Бывают ситуации, когда ни файл, ни каталог не будет найден. В таком случае загрузится файл по умолчанию - index.html. Правило try_files применяет последний параметр как запасной вариант. Именно поэтому данный файл должен быть в системе. Однако, если совпадений вообще не найдено, Nginx вернет страничку ошибки. Чтобы ее задать, пропишите = и код ошибки:
Дополнительные опции
Если применить правило alias, получится обслужить страницы блока location вне каталога root, например. Когда нужны файлы из doc, они будут запрошены из /usr/share/doc/. Кроме того, правило autoindеx on запускает листинг директорий сервера, для указанной директивы location. Если прописать строки deny и allow, получится изменить доступ к каталогам.
В качестве заключения стоит сказать, что Nginx - это очень мощный многофункциональный инструмент. Но чтобы разобраться хорошо с принципом его работы, потребуются время и усилия. Если понять работу конфигураций, вы сможете в полной мере наслаждаться всеми возможностями программы.
Nginx – это популярный и производительный веб-сервер и обратный прокси-сервер.
У Nginx много преимуществ, однако его настройки достаточно сложные и не всегда понятны новичкам. Данное руководство поможет разобраться с основными параметрами, синтаксисом и конфигурационными файлами Nginx.
Примечание : Руководство выполнено на Ubuntu 12.04.
Иерархия каталогов Nginx
Nginx хранит конфигурационные файлы в каталоге /etc/nginx.
В этом каталоге находится ещё несколько каталогов и модульных конфигурационных файлов.
cd /etc/nginx
ls -F
conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/ win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled/
Пользователи Apache уже знакомы с каталогами sites-available и sites-enabled. Эти каталоги определяют конфигурации сайтов. Файлы обычно создаются и хранятся в sites-available; в sites-enabled хранятся только конфигурации включенных сайтов. Для этого нужно создать символическую ссылку из sites-available в sites-enabled.
Каталог conf.d тоже можно использовать для хранения конфигураций. Каждый файл с расширением.conf будет читаться при запуске Nginx. Синтаксис таких файлов не должен содержать ошибок.
Почти все оставшиеся файлы хранятся в /etc/nginx, который содержит сведения о конфигурации конкретных процессов или дополнительных компонентов.
Главным конфигурационным файлом Nginx является nginx.conf.
Файл nginx.conf
Файл nginx.conf читает соответствующие конфигурационные файлы и объединяет их в единый файл конфигурации при запуске сервера.
Откройте файл:
sudo nano /etc/nginx/nginx.conf
user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events {
worker_connections 768;
# multi_accept on;
}
http {
. . .
Первые строки задают общие сведения о Nginx. Строка user www-data указывает пользователя, с помощью которого запускается сервер.
Директива pid указывает, где будут храниться PID процессов для внутреннего использования. Строка worker_processes определяет количество процессов, которое может одновременно поддерживать Nginx.
Также в этой части файла можно указать логи (например, лог ошибок определяется с помощью директивы error_log).
За общими сведениями о сервере следует раздел events. Он управляет обработкой соединений Nginx. За ним идёт блок http. Прежде чем продолжить ознакомление с конфигурациями веб-сервера, нужно понять, как отформатирован конфигурационный файл Nginx.
Структура конфигурационного файла Nginx
Конфигурационный файл Nginx делится на блоки.
Первый блок – events, за ним идёт http и начинается главная иерархия конфигураций.
Детали конфигурации блока http делятся на уровни при помощи закрытых блоков, которые наследуют свойства из блока, в котором они расположены. В блоке http хранится большая часть общих конфигураций Nginx, которые делятся на блоки server, которые, в свою очередь, делятся на блоки location.
Во время настройки Nginx важно помнить следующее правило: чем выше уровень конфигурации, тем больше блоков наследует эту конфигурацию; чем ниже уровень конфигурации, тем она «индивидуальнее». То есть, если параметр Х должен применяться в каждом блоке server, то такой параметр нужно поместить в блок http.
Если вы внимательно рассмотрите файл, вы заметите, что он содержит много опций, которые определяют поведение программы как единого целого.
Например, чтобы настроить сжатие файлов, нужно установить такие параметры:
gzip on;
gzip_disable "msie6";
Это включит поддержку gzip для сжатия отправляемых клиенту данных и отключит gzip для Internet Explorer 6 (поскольку этот браузер не поддерживает сжатия данных).
Если какой-либо параметр должен иметь разное значение в нескольких блоках server, то такой параметр можно задать на высшем уровне, а затем переопределить его внутри самих блоков server. В результате Nginx выполнит параметр низшего уровня.
Такое разбиение конфигураций на уровни позволяет избежать необходимости управлять несколькими идентичными файлами. Кроме того, если вы забыли определить параметры на низшем уровне, Nginx просто выполнит параметры по умолчанию.
Блок http в файле nginx.conf заканчивается так:
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
Это говорит о том, что блоки server и location, которые определяют настройки конкретных сайтов и URL-адресов, будут храниться за пределами этого файла.
Это позволяет поддерживать модульную архитектуру конфигураций, в которой можно создавать новые файлы для обслуживания новых сайтов. Также это позволяет группировать похожие файлы.
Закройте файл nginx.conf. Теперь нужно изучить настройки отдельных сайтов.
Виртуальные блоки Nginx
Блоки server в Nginx являются аналогом виртуальных хостов Apache (но для удобства их тоже принято называть виртуальными хостами). По сути, блоки server – это технические характеристики отдельных веб-сайтов, размещённых на одном сервере.
В каталоге sites-available можно найти файл блока server по умолчанию, который поставляется вместе с сервером. Этот файл содержит все необходимые данные для обслуживания сайта.
cd sites-available
sudo nano default
root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / {
}
location /doc/ {
alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;
Файл по умолчанию очень хорошо закомментирован, но в примере выше комментарии опущены для простоты и удобства.
Блок server включает в себя все настройки, помещённые между фигурными скобками:
server {
. . .
}
Этот блок размещён в файле nginx.conf ближе к концу блока http с помощью директивы include.
Директива root определяет каталог, в котором будет храниться контент сайта. В этом каталоге Nginx будет искать запрашиваемые пользователем файлы. По умолчанию это каталог /usr/share/nginx/www.
Обратите внимание: все строки заканчиваются точкой с запятой. Так Nginx отделяет одну директиву от другой. Если точки с запятой не будет, Nginx прочитает две директивы (или несколько директив) как одну директиву с дополнительными аргументами.
Директива index определяет файлы, которые будут использоваться в качестве индекса. Веб-сервер будет проверять файлы в порядке их перечисления. Если ни одна страница не была запрошена, блок server найдёт и вернёт файл index.html. Если он не сможет найти этот файл, он попытается обработать index.htm.
Директива server_name
Директива server_name содержит список доменных имен, которые будут обслуживаться этим блоком server. Количество доменов неограниченно; домены в списке следует разделять пробелами.
Символ звёздочки (*) в начале или конце домена задаёт имя с маской, где звёздочка соответствует части (или нескольким частям) имени. Например, имя *.example.com будет соответствовать именам forum.example.com и www.animals.example.com.
Если запрашиваемый url-адрес соответствует нескольким директивам server_name, он сначала ответит той, с которой совпадает полностью.
Если адрес не обнаружит совпадений, он будет искать самое длинное имя с маской, которое заканчивается звездочкой. Если он не найдёт такого имени, он вернёт первое соответствие с регулярными выражениями.
Имена сервера, которые используют регулярные выражения, начинаются с тильды (~). К сожалению, данная тема выходит за рамки данной статьи.
Блоки location
Строка location / указывает, что директивы в скобках будут применяться ко всем запрашиваемым ресурсам, которые не соответствуют никаким другим блокам location.
Такие блоки могут содержать uri путь (например /doc/). Чтобы установить полное соответствие между location и uri, используется символ =. Символ ~ устанавливает соответствие с регулярными выражениями.
Тильда включает чувствительный к регистру режим, а тильда со звёздочкой – регистронезависимый режим.
Если запрос полностью соответствует блоку location, то сервер останавливает поиск и использует такой блок. Если сервер не находит полностью подходящего блока location, он сравнивает URI с параметрами директив location. Nginx выберет блок, в котором используется сочетание символов ^~ и который совпадает с URI.
Если опция ^~ не используется, Nginx выберет наиболее близкое совпадение и выполнит поиск по регулярным выражениям, чтобы попробовать подобрать один из доступных шаблонов. Если он найдёт такое выражение, то он использует его. Если такого выражения нет, то сервер использует найденное ранее совпадение с URI.
В качестве заключения следует отметить, что Nginx предпочитает точные соответствия. Если таких соответствий нет, он ищет регулярное выражение, а затем выполняет поиск по URI. Чтобы изменить приоритетность поиска по URI, используйте комбинацию символов ^~.
Директива try_files
Директива try_files – очень полезный инструмент, который проверяет наличие файлов в заданном порядке и использует первый найденный файл для обработки запроса.
Это позволяет вам с помощью дополнительных параметров определить, как Nginx будет обслуживать запросы.
В конфигурационном файле по умолчанию есть строка:
try_files $uri $uri/ /index.html;
Это значит, что при поступлении запроса, обслуживаемого блоком location, Nginx сначала попробует обслужить uri как файл (такое поведение задаёт переменная $uri).
Если сервер не обнаруживает соответствия переменной $uri, он попробует использовать uri как каталог.
С помощью слэша в конце сервер проверяет существование каталога, например, $uri/.
Если ни один файл или каталог не найден, Nginx выполняет файл по умолчанию (в данном случае это index.html в root-каталоге блока server). Каждая директива try_files использует последний параметр в качестве запасного варианта, потому этот файл должен существовать в системе.
В случае, если веб-сервер не обнаружил совпадений в предыдущих параметрах, он может вернуть страницу ошибки. Для этого используется знак равно и код ошибки.
Например, если блок location / не может найти запрашиваемый ресурс, вместо файла index.html он может вернуть ошибку 404:
try_files $uri $uri/ =404;
Для этого нужно поставить знак равно и задать код ошибки в качестве последнего параметра (=404).
Дополнительные параметры
Директива alias позволяет Nginx обслуживать страницы блока location вне заданного каталога (например, вне root).
Например, файлы, запрашиваемые в /doc/, будут обслужены из /usr/share/doc/.
Директива autoindex on позволяет включает листинг директорий Nginx для заданной директивы location.
Строки allow и deny управляют доступом к каталогам.
Заключение
Веб-сервер Nginx является многофункциональным и очень производительным средством, однако его терминология и параметры могут показаться запутанными.
Разобравшись с конфигурациями Nginx и научившись работать с ними, вы получите все преимущества этого мощного и легковесного инструмента.
Tags: ,
