Налаштування конфігурації nginx на хостингу. Тонка настройка Nginx. Захист, оптимізація. Віртуальний хост – це…

14 серпня 2009 о 19:29

Налаштування nginx

Nginx

Тема правильного налаштування nginx дуже велика, і, боюсь, в рамках однієї статті на хабрі ніяк не міститься. У цьому тексті я постарався розповісти про загальну структуруконфіга, більш цікаві дрібниці та зокрема, можливо, будуть пізніше. :)

Непоганою початковою точкою для налаштування nginx є конфіг, який йде в комплекті з дистрибутивом, але багато можливостей цього сервера в ньому навіть не згадуються. Значно більше докладний прикладє на сайті Ігоря Сисоєва: sysoev.ru/nginx/docs/example.html. Однак, давайте краще спробуємо зібрати з нуля свій конфіг, з бриджем та поетесами. :)

Почнемо з загальних налаштувань. Спочатку вкажемо користувача, від імені якого працюватиме nginx (від рута працювати погано, всі знають:))

Тепер скажемо nginx-у, скільки робочих процесів породити. Зазвичай, гарним виборомбуває число процесів, що дорівнює кількості процесорних ядер у вашому сервері, але з цим налаштуванням має сенс поекспериментувати. Якщо очікується високе навантаження на жорсткий диск, можна зробити за процесом на кожен фізичний жорсткий диск, оскільки вся робота буде все одно обмежена його продуктивністю.

Worker_processes 2;

Уточнимо, куди писати логи помилок. Потім, для окремих віртуальних серверів, цей параметр можна перевизначити, так що в цей лог будуть сипатися лише «глобальні» помилки, наприклад, пов'язані зі стартом сервера.

Error_log /spool/logs/nginx/nginx.error_log notice; # рівень повідомлень "notice", звичайно, можна міняти

Тепер йде дуже цікава секція Events. У ній можна поставити максимальна кількістьз'єднань, які одночасно буде обробляти один процес-воркер, і метод, який використовуватиметься для отримання асинхронних повідомлень про події в ОС. Звичайно, можна вибрати тільки ті методи, які доступні на вашій ОС і були включені при компіляції.

Ці параметри можуть вплинути на продуктивність вашого сервера. Їх треба підбирати індивідуально, залежно від ОС та заліза. Я можу навести лише кілька загальних правил.

Модулі роботи з подіями:
- select і poll зазвичай повільніше і досить сильно навантажують процесор, проте доступні практично скрізь, і працюють практично завжди;
- kqueue та epoll - більш ефективні, але доступні тільки у FreeBSD та Linux 2.6, відповідно;
- rtsig - досить ефективний метод, і підтримується навіть дуже старими лінуксами, але може викликати проблеми при великому числіпідключень;
- /dev/poll - наскільки мені відомо, працює в дещо більше екзотичних системах, типу солярісу, і в ньому досить ефективний;

Параметр worker_connections:
- Загальна максимальна кількість клієнтів, що обслуговуються, дорівнюватиме worker_processes * worker_connections;
- Іноді можуть спрацювати у позитивний бікнавіть найекстремальніші значення, на кшталт 128 процесів, по 128 коннектів на процес, або 1 процесу, але з параметром worker_connections=16384. В останньому випадку, втім, швидше за все знадобиться тюнити ОС.

Events (
worker_connections 2048;
use kqueue; # У нас BSD:)
}

Наступна секція – найбільша, і містить найцікавіше. Це опис віртуальних серверів та деяких параметрів, спільних для них усіх. Я опущу стандартні налаштування, які є у кожному конфізі, типу шляхів до логів.

Http (
# Весь код нижче буде всередині цієї секції %)
# ...
}

Усередині цієї секції можуть бути кілька досить цікавих параметрів.

Системний виклик sendfile з'явився на Linux відносно недавно. Він дозволяє відправити дані до мережі, минаючи етап їх копіювання в адресний простір програми. У багатьох випадках це істотно підвищує продуктивність сервера, тому параметр sendfile краще завжди включати.

Параметр keepalive_timeout відповідає за максимальний часпідтримки keepalive-з'єднання, у випадку, якщо користувач по ньому нічого не запитує. Обміркуйте, як саме на вашому сайті надсилаються запити, та виправте цей параметр. Для сайтів, що активно використовують AJAX, з'єднання краще тримати довше, для статичних сторінок, які користувачі будуть довго читати, з'єднання краще розривати раніше. Врахуйте, що підтримуючи неактивне keepalive-з'єднання, ви займаєте коннекшн, який міг би використовуватися по-іншому. :)

Keepalive_timeout 15;

Окремо варто виділити налаштування проксіювання nginx. Найчастіше, nginx використовується саме як сервер-проксі, відповідно вони мають досить велике значення. Зокрема, розмір буфера для запитів, що проксуються, має сенс встановлювати не менше, ніж очікуваний розмір відповіді від сервера-бекенда. При повільних (або, навпаки, дуже швидких) бекендах, є сенс змінити таймаути очікування відповіді від бекенда. Пам'ятайте, чим більше ці таймати, тим довше чекатимуть відповіді ваші користувачі, при гальмах бекенда.

Proxy_buffers 8 64k;
proxy_intercept_errors on;
proxy_connect_timeout 1s;
proxy_read_timeout 3s;
proxy_send_timeout 3s;

Невеликий трюк. У випадку, якщо nginx обслуговує більш ніж один віртуальний хост, має сенс створити «віртуальний хост за замовчуванням», який оброблятиме запити в тих випадках, коли сервер не зможе знайти іншої альтернативи за заголовком Host у запиті клієнта.

# default virtual host
server (
listen 80 default;
server_name localhost;
deny all;
}

Далі може йти одна (або кілька) секцій «server». У кожному їх описується віртуальний хост (найчастіше, name-based). Для власників безлічі сайтів на одному хостингу, або для хостерів тут може бути щось на кшталт директиви

Include /spool/users/nginx/*.conf;

Інші, швидше за все, опишуть свій віртуальний хост прямо в основному конфізі.

Server (
listen 80;

# Зверніть увагу, що в директиві server_name можна вказати кілька імен одночасно.
server_name myserver.ru myserver.com;
access_log /spool/logs/nginx/myserver.access_log timed;
error_log /spool/logs/nginx/myserver.error_log warn;
# ...

Встановимо кодування для віддачі за замовчуванням.

Charset UTF-8;

І скажемо, що ми не хочемо приймати від клієнтів запити довжиною більш ніж 1 мегабайт.

Client_max_body_size 1m;

Включимо для сервера SSI та попросимо для SSI-змінних резервувати не більше 1 кілобайта.

Ssi on;
ssi_value_length 1024;

І, нарешті, опишемо два локейшні, один з яких вестиме на бекенд, до апачу, запущеному на порту 9999, а другий віддаватиме статичні картинки з локальної файлової системи. Для двох локейшнів це малоосмислено, але для більшого їх числа має сенс також відразу визначити змінну, в якій зберігатиметься кореневий каталог сервера, і потім використовуватиме її в описах локацій.

Веб- сервер Nginx- це один з найпопулярніших веб-серверів з дуже високою продуктивністю та швидкою обробкою статичних запитіввід користувачів. При правильному налаштуванні можна досягти дуже високої продуктивності від цього веб-сервера. Nginx дуже швидко справляється зі статичними файлами, будь то html сторінкичи інші види ресурсів.

В одній із попередніх статей ми вже розглядали і налаштування його основних параметрів, у цій статті я хочу більше зупинитися на продуктивності та підготовці веб-сервера до використання в бойових умовах. Що стосується дистрибутива Linux, то сьогодні ми розглядатимемо CentOS, ця система часто використовується на серверах і з налаштуванням Nginx тут можуть виникнути деякі складнощі. Далі буде розглянуто налаштування Nginx CentOS, поговоримо як увімкнути повну підтримку http2, google pagespeed, та налаштувати основний конфігураційний файл.

В офіційних репозиторіях CentOS є Nginx, і він, швидше за все, вже встановлений у вашій системі. Але ми хочемо, щоб сайт працював за протоколом http2, який дозволяє передавати всі дані одним підключенням, а це збільшує продуктивність. Для роботи по http2 вам знадобиться налаштувати SSL сертифікат, але про це вже написано у статті отримання сертифіката Lets Encrypt Nginx. Але це ще не все. для перемикання зі звичайного SSL на HTTP2.0 у більшості браузерів зараз використовується протокол ALPN, а він підтримується, починаючи з OpenSSL 1.02. У той час як у репозиторіях є тільки OpenSSL 1.01. Тому потрібно встановити версію Nginx, зібрану з OpenSSL 1.02. Для цього можна використовувати Broken Repo:

sudo yum -y install yum-utils
# sudo yum-config-manager --add-repo https://brouken.com/brouken.repo

Якщо ви використовуєте репозиторій EPEL, то потрібно вказати, що не треба з нього брати Nginx:

sudo yum-config-manager --save --setopt=epel.exclude=nginx*;

Тепер для встановлення правильної версії Nginx достатньо набрати:

sudo yum install nginx

Буде встановлена сама остання версія Nginx 1.13.2 з повною підтримкою ALPN. Далі перейдемо до налаштування.

2. Налаштування Nginx

Насамперед слід розглянути структуру конфігураційного файла. На перший погляд, тут все може здатися дуже заплутаним, але все досить логічно:

глобальні опції
events ()
http(
server (
location()
}
server()
}

Спочатку йдуть глобальні опції, які визначають основні параметри програми, наприклад, від якого користувача вона буде запущена і кількість процесів. Далі є секція events, в якій описано як Nginx буде реагувати на вхідні підключення, потім йде секція http, яка об'єднує всі налаштування щодо роботи протоколу http. У ній знаходиться секція server, кожна така секція відповідає за окремий домен, у секції server розміщуються секції location, кожна з яких відповідає за певний URL запитуЗверніть увагу, що не файл на сервері, як в Apache, а саме URL запиту.

Основні глобальні налаштуваннями робитимемо у файлі /etc/nginx/nginx.conf. Далі розглянемо що саме змінюватимемо і які значення бажано встановити. Почнемо з глобальних опцій:

user- користувач, від імені якого буде запущено сервер, повинен бути власником каталогу з файлами сайту, і від імені його потрібно запускати php-fpm;
worker_processes- кількість процесів Nginx, які будуть запущені, потрібно встановити рівно стільки, скільки у вас є ядер, наприклад, у мене – 4;
worker_cpu_affinity- цей параметр дозволяє закріпити кожен процес за окремим ядром процесора, встановіть значення auto, щоб програма сама вибрала, що і до чого кріпити;
worker_rlimit_nofile- максимальна кількість файлів, які може відкрити програма, на кожне з'єднання потрібно як мінімум два файли і кожен процес матиме вказану кількість з'єднань, тому формула така: worker_processes * worker_connections* 2, параметр worker_connectionsрозберемо трохи нижче;
pcre_jit- увімкніть цей параметр для прискорення обробки регулярних виразівза допомогою JIT компіляції;

У секції events варто налаштувати два параметри:

worker_connections- кількість сполук для одного процесу повинна бути достатньою для обробки вхідних сполук. Спочатку нам потрібно знати, скільки цих вхідних сполук є, для цього дивимося статистику за адресою ip_сервера/nginx_status. Як увімкнути розглянемо нижче. У рядку Active Connections бачимо кількість активних з'єднань із сервером, також потрібно врахувати, що з'єднання з php-fpm теж вважаються. Далі зверніть увагу на поля accepted і handled, перше відображає оброблені підключення, друге - кількість прийнятих. Зі значення повинні бути однаковими. Якщо відрізняються значить з'єднань не вистачає. Дивіться приклади, перший знімок проблема, другий – порядок. Для моєї конфігурації оптимальною може бути цифра в 200 з'єднань (всього 800, враховуючи 4 процеси):

multi_accept- дозволяє програмі приймати кілька з'єднань одночасно, що теж прискорює роботу, при великій кількості з'єднань;
accept_mutex- встановіть значення цього параметра в off, щоб одразу всі процеси отримували повідомлення про нові з'єднання;

Також у секції events рекомендується використовувати директиву use epoll, оскільки цей найефективніший метод обробки вхідних з'єднань для Linux, але цей метод застосовується за умовчанням, тому не бачу сенсу додавати його вручну. Розглянемо ще кілька параметрів із секції http:

sendfile- Використовувати метод відправлення даних sendfile. Найефективніший метод для Linux.
tcp_nodelay, tcp_nopush- відправляє заголовки та тіло запиту одним пакетом, працює трохи швидше;
keepalive_timeout- тайму підтримки з'єднання з клієнтом, якщо у вас немає дуже повільних скриптів, то буде достатньо буде 10 секунд, встановлюємо значення скільки потрібно, щоб користувач міг бути підключений до сервера;
reset_timedout_connection- Розривати з'єднання після таймууту.
open_file_cache- кешувати інформацію про відкритих файлів. Наприклад, open_file_cache max=200000 inactive=120s; max – максимальна кількість файлів у кеші, час кешування.
open_file_cache_valid- коли необхідно перевірити актуальність файлів. Наприклад: open_file_cache_valid 120s;
open_file_cache_min_uses- кешувати тільки файли, які були відкриті вказану кількість разів;
open_file_cache_errors- Запам'ятовувати помилки відкриття файлів.
if_modified_since- встановлює, яким чином будуть оброблятися заголовки if-modified-since. За допомогою цього заголовка браузер може отримати відповідь 304, якщо сторінка не змінилася з моменту останнього перегляду. Можливі варіанти - не відправляти - off, відправляти за точного збігу часу - exact, відправляти якщо час збігається точно або більше - before;

Ось якось так виглядатиме налаштування nginx conf:

user nginx;
worker_processes 4;
worker_cpu_affinity auto;
worker_rlimit_nofile 10000;
pcre_jit on;

error_log /var/log/nginx/error.log warn;
load_module "modules/ngx_pagespeed.so";

events (
multi_accept on;
accept_mutex off;
worker_connections 1024;
}

sendfile on;
tcp_nopush on;
tcp_nodelay on;

open_file_cache max=200000 inactive=20s;
open_file_cache_valid 120s;
open_file_cache_errors on;

reset_timedout_connection on;
client_body_timeout 10;
keepalive_timeout 65;

include /etc/nginx/sites-enabled.*.conf

3. Налаштування http2

Я не буду детально описувати налаштування секції server, тому що робив це вже в статті встановлення Nginx в Ubuntu і тут мені нема чого додати, налаштування SSLце досить велика тема і також буде розглянута в окремій статті. Але, щоб налаштувати http2 вам потрібно мати вже SSL. Далі, просто підправте директиву listen у вашій секції server:

listen 194.67.215.125:443 default_server;

listen 194.67.215.125:443 http2 default_server;

Ось таким простим способомможна ввімкнути http2 якщо перед цим було встановлено правильна версія Nginx.

4. Налаштування PageSpeed

Google Pagespeed - це модуль Nginx, який виконує різні оптимізації для того, щоб сторінки вантажилися швидше, веб-сервер працював ефективніше, а користувачі не відчували дискомфорту. Сюди входить кешування, оптимізація html коду, оптимізація картинок, об'єднання javascriptі css кодуі багато іншого. Все це виконується на рівні Nginx, тому ефективніше, ніж якщо ви це робили в php. Але тут є один недолік, модуль видаляє заголовок Last Modified.

Справа в тому, що PageSpeed встановлює дуже довгий рядок кешування для всіх файлів, а в ім'я файлу додає його хеш. Так швидкість завантаження ресурсів виходить набагато вище, оскільки браузер буде запитувати файли тільки з новим хешем, а LastModified видаляється, щоб користувачі змогли побачити зміни, якщо який-небудь файл буде змінено. А тепер розглянемо, як встановити модуль. Нам доведеться зібрати його із вихідних кодів.

Спочатку встановіть інструменти для складання, дуже важливо, якщо не встановите, потім отримаєте помилку і не знатимете що робити:

yum install wget gcc cmake unzip gcc-c++ pcre-devel zlib-devel

Завантажте та розпакуйте вихідні дані Nginx для вашої версії, наприклад, 1.13.3:

wget -c https://nginx.org/download/nginx-1.13.3.tar.gz
# tar -xzvf nginx-1.13.3.tar.gz

Налаштування сервера nginx не включає перескладання та заміну програми з репозиторію, ми просто використовуємо ці вихідники для складання модуля. Завантажте та розпакуйте вихідні PageSpeed:

wget -c https://github.com/pagespeed/ngx_pagespeed/archive/v1.12.34.2-stable.zip
# unzip v1.12.34.2-stable.zip

Завантажте та розпакуйте бібліотеку оптимізації PageSpeed у папку з вихідними модулями:

cd ngx_pagespeed-1.12.34.2-stable/
# wget -c https://dl.google.com/dl/page-speed/psol/1.12.34.2-x64.tar.gz
# tar -xvzf 1.12.34.2-x64.tar.gz

Завантажте та розпакуйте вихідні коди OpenSSL 1.02:

wget -c https://www.openssl.org/source/openssl-1.0.2k.tar.gz -O /opt/lib/$OPENSSL.tar.gz
# tar xvpzf openssl-1.0.2k.tar.gz

Тепер нам потрібно зібрати модуль. Спочатку дивимося налаштування, з якими зібраний поточний Nginx:

А тепер переходимо в папку з Nginx, підставляємо всі отримані опції, опцію --add-dynamic-module для PageSpeed, OpenSSL і пробуємо зібрати:

cd nginx-1.13.3
# ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx .conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx .pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache /nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path= /var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module ule --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt="- O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic" --with- ld-opt= --with-openssl=$HOME/openssl-1.0.2k --add-dynamic-module=$HOME/ngx_pagespeed-1.12.34.2-stable $(PS_NGX_EXTRA_FLAGS)
# make

Якщо все було зроблено правильно, то на виході ви отримаєте модуль ngx_pagespeed.so у папці obj, його потрібно скопіювати в папку /etc/nginx/modules:

cp ngx_pagespeed.so /etc/nginx/modules/ngx_pagespeed.so

Створюємо папку для кешу:

mkdir -p /var/ngx_pagespeed_cache
# chown -R nginx:nginx /var/ngx_pagespeed_cache

Тепер додайте такий рядок для включення модуля /etc/nginx/nginx.conf:

load_module "modules/ngx_pagespeed.so";

Один із найпопулярніших веб-серверів

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 розділені на рівні за допомогою закритих блоків. Вони успадковують характеристики з батьківського, тобто. того, в якому розташовуються. Цей блокзберігає більшість конфігурацій сервера. Вони поділяються на блоки сервера, всередині яких розташовані місцезнаходження.

Коли ви налаштовуєте сервер 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 - це дуже потужний багатофункціональний інструмент. Але щоб розібратися добре з принципом його роботи, знадобиться час та зусилля. Якщо зрозуміти роботу конфігурацій, ви зможете повною мірою насолоджуватися всіма можливостями програми.

Привіт, Шановний користувачХабрахабра. Моя розповідь буде про те, як підготувати ґрунт для локальної веб-розробки проектів в операційній системі Ubuntu 16.04.1 LTS.

У цій статті хочеться розвіяти та роз'яснити можливі труднощіпов'язані з установкою та налаштуванням ПЗ, яке потрібно для сучасної веб-розробки, З якими можливо стикаються розробники-початківці і не тільки.

Технології, які будуть використані в статті: nginx, php-fpm.

Перед початком розповіді, хочу зазначити, що я робив усі ці дії на «голій» системі.
Я працюватиму з пакетним менеджером aptitude. Також рекомендую оновити індекс пакетів і самі пакети перед встановленням ПЗ. У статті ми зробимо ці дії разом.

Поїхали!

Встановлення пакетного менеджера aptitude, оновлення індексу та пакетів

Встановлюємо:

Sudo apt install aptitude
Оновлюємо індекс.

Sudo aptitude update
Оновлюємо пакети (команда оновить усі пакети, для яких є нові версії, якщо потрібно видалити пакети, то воно буде виконано).

Sudo aptitude full-upgrade

Встановлення та налаштування nginx(версія> = 1.10.0)

Встановлюємо.

Sudo aptitude install nginx
Запускаємо.

Sudo service nginx start
Перевіряємо версію, щоб переконатися, що не встановили стару, тобто нижче 1.10.0.

Установку та запуск зробили, тепер підемо в каталог туди, куди встановлений наш nginx і подивимося на його структуру. Каталог nginx знаходиться таким шляхом:

Cd /etc/nginx/
Подивитися вміст директорії можна командою ls, з прапорами -la зручніше переглядатиме вміст каталогу (насправді цю команду з конкретними прапорами можна описати детальніше та вірніше, але у нас сьогодні інша тема).

Ls-la
Наc цікавлять у Наразідва каталоги, які ви бачите на скріншоті. Це каталоги sites-available та sites-enabled.

Давайте перейдемо в каталог sites-available та почнемо конфігурувати наш віртуальний хост (сайт).

Cd /etc/nginx/sites-available
Перед початком створення конфігураційного файлу, перевіримо, що лежить у нас в даному каталозі. У моєму випадку каталог не порожній, у ньому вже є конфігураційні файли, я їх затер, щоб не вводити вас в оману.

Важливий відступ

У разі встановлення nginx "з нуля", саме "з нуля", тому що при видаленні nginx командою
sudo apt-get remove nginx або sudo apt remove nginx конфігураційні файли залишаються і якщо ви раптом будете не розуміти, чому nginx не працює і захочете його перевстановити (зазвичай до такого вдаються початківці користувачі Linux), то і після переустановки він не буде коректно працювати, тому що в старих конфігураційних файлах (вони не видаляються після видалення командою remove) прописані неправильні налаштування, їх доведеться видалити, або налаштувати правильно, тільки тоді nginx запрацює.

Рекомендую видаляти командою sudo apt-get purge nginx або sudo apt purge nginx. Якщо ви використовуєте пакетний менеджер aptitude, то команда sudo aptitude purge nginx видаляє пакет повністю з усіма залежностями та конфігураційними файлами.

У цьому каталозі буде за промовчанням один файл під назвою default. У ньому буде конфігураційний файл з прикладом, з коментарями, його ви можете вивчити на дозвіллі, а можете взагалі видалити (завжди можна звернутися до офіційної документації).

Ls-la

Створимо свій конфігураційний файл, який відповідатиме назві домену нашого локального сайту (або реального, якщо вже знаєте його назву). Це зручно, в майбутньому, коли буде багато конфігураційних файлів, це позбавить вас від плутанини в них. У мене цей файл називатиметься project.local.

Sudo touch project.local
Подивимося, що вийшло.

Тепер відкриємо його у редакторі, я відкрию його у nano.

Sudo nano project.local
Бачимо, що він у нас порожній. Тепер перейдемо до формування нашого файлу. Потрібно привести конфігурацію до такого виду, як написано нижче. Я опишу тільки життєво важливі директиви цього файлу, описувати інше не буду, так як це не є на даний момент важливим, все ж таки у нас тема базового налаштування. Цих налаштувань із «гіркою» вистачить для розробки проектів локально, не лише дрібних, а й досить великих. У наступних статтях опишу окремо кожні використані директиви (саме так називаються рядки, наприклад server_name) цього файлу.

Дивіться коментарі прямо в конфігураційному файлі.

Server ( listen 80; # порт, що прослуховує nginx server_name project.local; # доменне ім'я, що відносяться до поточного віртуальному хосту root /home/stavanger/code/project.local; # каталог, у якому лежить проект, шлях до точки входу index index.php;
# add_header Access-Control-Allow-Origin*;

# serve static files directly location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ ( access_log off; expires max; log_not_found off; ) location / ( # add_header Access-Control-Allow- Origin *; try_files $uri $uri/ /index.php? $query_string; :/var/run/php/php7.0-fpm.sock; # підключаємо сокет php-fpm fastcgi_index ; SCRIPT_FILENAME $document_root$fastcgi_script_name ()
Зберігаємо файл. Тепер нам треба перевірити, чи в ньому немає помилок. Зробити ми можемо командою.

Sudo nginx -t

Якщо бачимо таку інформацію як на скріншоті, значить у нас все правильно, може продовжувати налаштування. Якщо ви отримуєте будь-які помилки, варто перевірити ще раз конфігураційний файл.
Тепер нам треба активувати конфігураційний файл, у каталозі /etc/nginx/sites-enabled/ необхідно створити симлінк (символічна посилання). Якщо у вас nginx був встановлений з нуля, то в цьому каталозі є симлінк на файл default, про який розповідалося вище, його можна видалити, якщо він вам не потрібно. Переходимо до потрібного каталогу. Cd /etc/nginx/sites-enabled/Тепер ми в

потрібному каталозі
. Давайте створимо наш симлінк. Для створення використовується команда ln із прапором -s, далі ми вкажемо шлях до нашого конфігу project.local.

Sudo ln -s /etc/nginx/sites-available/project.local

Подивимося на наш створений симлінк. Щоб переконатися, що ми робимо ще все вірно, знову запустимо команду.

Файл hostsЦей файл знаходиться на шляху /etc/hosts. Наявність в ньому записів дозволяє запускати nginx з використанням в якості домену localhost. У цьому файлі можна надавати

альтернативні псевдоніми

наприклад, для нашого проекту project.local, ми надамо домен project.local.
Відкриваємо файл у редакторі nano.

Sudo nano /etc/hosts У вас у цьому файлі буде інша інформація, просто ігноруйте її. Вам лише потрібно додати рядок як на моєму скріншоті. (>=7.0)

Встановлення
php-fpm sudo aptitude install php-fpmПеревіряємо

встановлену версію

, про всяк випадок, хоча в Ubuntu 16.04.1 у репозиторіях лежить саме 7.0 версія.

Php-fpm7.0-v
Якщо правитимете конфіги, то не забувайте рестартувати демон. Це так. Але нам це не буде потрібно.

Sudo service php7.0-fpm restart
На цьому встановлення та налаштування php-fpmзакінчено. Щоправда, це все. Це не магія, шлях до сокету php-fpm у нас вже був прописаний у файлі конфігурації. Звичайно, вам можуть знадобитися будь-які розширення phpдля розробки особистих проектів, але їх ви можете поставити в міру того, як вони будуть потрібні.

Тепер підемо до каталогу з нашим проектом, у мене він лежить таким шляхом.

Cd /home/stavanger/code/project.local
Піднімемося на каталог вище та зробимо права 777 (тобто ми будемо робити повні правакаталогу з нашим проектом (project.local). У майбутньому це позбавимо нас зайвих проблем.

Cd .. sudo chmod -R 777 project.local
На цьому налаштування ПЗ завершено, давайте створимо тестовий файл у нашому робочому каталозі project.local і переконаємось, що все працює. Я створю файл index.php з таким змістом.

Йдемо в браузер і бачимо, що у нас все чудово працює! Інтерпретатор php у тому числі.

З повагою до читачів, Ставангер.

Виділений 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 Мб може зберігати близько 32 000 станів, ми встановлюємо її розмір рівним 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 persist
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 flush)

Крім ліміту кількість послідовних підключень (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 не просідати навіть під дуже високими навантаженнями, витримуючи понад 10 000 одночасних з'єднань (так звана проблема C10K). Спочатку написаний Ігорем Сисоєвим для компанії Rambler і відкритий у 2004 році під BSD-подібною ліцензією.

Вконтакте