Конфигуриране на Nginx за производителност и сигурност

В този урок ще разгледаме как можем да конфигурираме уеб сървъра на Nginx за производствена среда.


Уеб сървърът в производствена среда е различен от уеб сървъра в тестова среда по отношение на производителност, сигурност и т.н..

По подразбиране винаги има готова за използване настройка за конфигурация за уеб сървър на Nginx, след като я инсталирате успешно. Конфигурацията по подразбиране обаче не е достатъчно добра за производствена среда. Затова ще се съсредоточим върху това как да конфигурираме Nginx да се представя по-добре по време на тежък и нормален скок на трафика и как да го защитим от потребители, които възнамеряват да го злоупотребяват..

Ако не сте инсталирали Nginx на вашата машина, можете да проверите как да направите това тук. Той ви показва как да инсталирате Nginx на Unix платформа. Изберете да инсталирате Nginx чрез изходните файлове, защото предварително изграденият Nginx не идва с някои от модулите, използвани в този урок.

Изисквания

Трябва да имате инсталирано следното на вашата машина и да се уверите, че стартирате този урок на всяка платформа, базирана на Debian, като Ubuntu.

  • Ubuntu или друга платформа, базирана на Debian
  • Wget
  • Vim (текстов редактор)

Също така, трябва да стартирате или изпълнявате някои команди в този урок като root потребител чрез командата sudo.

Разбиране на структурата за конфигуриране на Nginx

В този раздел ще разгледаме следното:

  • Структура на Nginx
  • Раздели като събитие, HTTP и поща
  • Валиден синтаксис на Nginx

В края на този раздел ще разберете структурата на конфигурацията на Nginx, целта или ролите на секциите, както и как да дефинирате валидни директиви вътре в секциите.

Пълният конфигурационен файл на Nginx има логическа структура, която се състои от директиви, групирани в няколко секции, като раздел за събития, раздел за http, пощенски раздел и т.н..

Основният конфигурационен файл се намира на /etc/nginx/nginx.conf, докато други файлове за конфигурация се намират в / etc / nginx.

Основен контекст

Този раздел или контекст съдържа директиви извън конкретни раздели, като например секцията за поща.

Всякакви други директиви като потребителски nginx; , Работник_процеси 1; , Error_log /var/log/nginx/error.log предупреждават; и pid /var/run/nginx.pid може да бъде поставен в основния раздел или контекст.

Но някои от тези директиви, като работници_процеси, могат да съществуват и в секцията за събития.

Секции

Секциите в Nginx определя конфигурацията за Nginx модулите.

Например секцията http определя конфигурацията за ngx_http_core модула, разделът за събитията определя конфигурацията за ngx_event_module, докато секцията за поща определя конфигурацията за ngx_mail_module.

Можете да проверите тук за пълен списък на секциите в Nginx.

директиви

Директивите в Nginx са съставени от име на променлива и редица аргументи като следните:

Работното_процеси е име на променлива, докато автото служи като аргумент.

работник_процеси автоматично;

Директивите завършват с двоеточие, както е показано по-горе.

И накрая, конфигурационният файл на Nginx трябва да се придържа към определен набор от правила. Следните са валиден синтаксис на конфигурация Nginx:

  • Валидните директиви започват с име на променлива, след което последват един или повече аргументи
  • Всички валидни директиви завършват с точка и запетая;
  • Секциите са дефинирани с къдрави скоби {}
  • Секция може да бъде вградена в друга секция
  • Конфигурацията извън който и да е раздел е част от глобалната конфигурация на Nginx.
  • Редките, започващи с хеш знак #, са коментари.

Настройка на Nginx за ефективност

В този раздел ще конфигурираме Nginx да се представя по-добре по време на тежък трафик и скок на трафика.

Ще разгледаме как да конфигурирате:

  • Работниците
  • Дисково I / O дейност
  • Мрежова активност
  • Буфери
  • компресия
  • кеширане
  • Timeout

И все пак вътре в активираната виртуална среда въведете следните команди, за да преминете в директорията Nginx и избройте съдържанието й.

CD nginx && LS

Търсене на конфигурацията на папката Вътре в тази папка е файлът nginx.conf.

Ще използваме този файл за конфигуриране на Nginx

Сега изпълнете следните команди, за да отидете до папката conf и отворете файла nginx.conf с редактора на vim

CD конф
sudo vim nginx.conf

По-долу е екранна снимка на това как изглежда файлът nginx.conf по подразбиране.

Работниците

За да позволим на Nginx да се представи по-добре, трябва да конфигурираме работниците в секцията за събития. Конфигурирането на Nginx служители ви позволява ефективно да обработвате връзки от клиенти.

Ако приемем, че не сте затворили редактора на vim, натиснете бутона i на клавиатурата, за да редактирате файла nginx.conf.

Копирайте и поставете следното в секцията за събития, както е показано по-долу:

събития {
работник_процеси автоматично;
работни връзки 1024;
работник_рлимит_нофил 20960;
multi_accept включен;
mutex_accept включен;
mutex_accept_delay 500ms;
използвайте epoll;
epoll_events 512;
}

работни_процеси: Тази директива контролира броя на работниците в Nginx. Стойността на тази директива е настроена на автоматично, за да позволи на Nginx да определи броя на наличните ядра, дисковете, зареждането на сървъра и мрежовата подсистема. Можете обаче да откриете броя на ядрата, като изпълните командата lscpu на терминала.

working_connections: Тази директива задава стойността на броя на едновременната връзка, която може да бъде отворена от работник. Стойността по подразбиране е 512, но ние я зададем на 1,024, за да позволи на един работник да приеме много едновременна връзка от клиент.

worker_rlimit_nofile: Тази директива по някакъв начин е свързана с работни връзки. За да се справим с голяма едновременна връзка, ние я задаваме на голяма стойност.

multi_accept: Тази директива позволява на работника да приема много връзки в опашката едновременно. Опашка в този контекст просто означава поредица от обекти, които чакат да бъдат обработени.

mutex_accept: Тази директива е изключена по подразбиране. Но тъй като сме конфигурирали много работници в Nginx, трябва да го включим, както е показано в кода по-горе, за да позволим на работниците да приемат нови връзки една по една.

mutex_accept_delay: Тази директива определя колко дълго трябва да чака работникът, преди да приеме нова връзка. След като accept_mutex е включен, мутекс заключване се присвоява на работник за времеви интервал, определен от accept_mutex_delay. Когато времето е изтекло, следващият работник на линия е готов да приеме нови връзки.

използване: Тази директива определя метода за обработка на връзка от клиента. В този урок решихме да зададем стойността за еполиране, защото работим върху платформа Ubuntu. Методът epoll е най-ефективният метод за обработка за Linux платформи.

epoll_events: Стойността на тази директива определя броя на събитията, които Nginx ще прехвърли към ядрото.

Диск I / O

В този раздел ще конфигурираме асинхронна I / O активност в Nginx, за да й позволим да извършва ефективен трансфер на данни и да подобри ефективността на кеша.

Disk I / O просто се отнася до операции за запис и четене между твърдия диск и RAM. Ще се възползваме от sendfile () функция вътре в ядрото за изпращане на малки файлове.

Можете да използвате http секцията, секцията за местоположение и секцията на сървъра за директиви в тази област.

Разделът за местоположение, секцията на сървъра може да бъде вграден или поставен в секцията http, за да направи конфигурацията четена.

Копирайте и поставете следния код в секцията за местоположение, вградена в секцията HTTP.

местоположение / pdf / {
sendfile on;
aio на;
}

местоположение / аудио / {
directio 4m
directio_alignment 512
}

sendfile: За да използвате ресурсите на операционната система, включете стойността на тази директива. sendfile прехвърля данни между файлови дескриптори в пространството на ядрото на OS, без да го изпраща в буферите на приложението. Тази директива ще се използва за обслужване на малки файлове.

directio: Тази директива подобрява ефективността на кеша, като позволява четене и запис да се изпраща директно в приложението. directio е функция на файлова система на всяка съвременна операционна система. Тази директива ще се използва за обслужване на по-големи файлове като видеоклипове.

aio: Тази директива дава възможност за многократно нарязване, когато е включена за операция запис и четене. Multi-threadading е модел за изпълнение, който позволява на няколко нишки да се изпълняват отделно един от друг, докато споделят своите ресурси на хостинг процеса.

directio_alignment: Тази директива присвоява стойност на размера на блока за прехвърляне на данни. Той беше свързан с директивата директива.

Мрежов слой

В този раздел ще използваме директиви като tcp_nodelay и tcp_nopush, за да предотвратим чакането на малки пакети за определен интервал от около 200 милисекунди, преди да бъдат изпратени наведнъж.

Обикновено, когато пакетите се прехвърлят на „парчета“, те са склонни да насищат силно натоварената мрежа. Така Джон Нагъл построил буферен алгоритъм за разрешаване на този проблем. Целта на алгоритъма за буфериране на Nagle е да предотврати насищането на малки пакети от силно заредената мрежа.

Копирайте и поставете следния код в секцията HTTP.

http {

tcp_nopush включен;
tcp_nodelay включен;

}

tcp_nodelay: Тази директива по подразбиране е деактивирана, за да позволи на малките пакети да изчакат определен период, преди да бъдат изпратени наведнъж. За да разрешите изпращането на всички данни наведнъж, тази директива е активирана.

tcp_nopush: Тъй като сме активирали директивата tcp_nodelay, малки пакети се изпращат наведнъж. Ако все пак искате да използвате алгоритъма за буфериране на Джон Nagle, можем също така да дадем възможност на tcp_nopush да добавя пакети един към друг и да ги изпращаме всички наведнъж.

Буфери

Нека да разгледаме как да конфигурирате буферите за заявки в Nginx, за да обработват ефективно заявките. Буферът е временно хранилище, където данните се съхраняват за известно време и се обработват.

Можете да копирате по-долу в секцията на сървъра.

сървър {

client_body_buffer_size 8k;
client_max_body_size 2m;
client_body_in_single_buffer е включен;
client_body_temp_pathtemp_files 1 2;
client_header_buffer_size 1м;
big_client_header_buffers 4 8k;

}

Важно е да се разбере какво правят тези буферни линии.

client_body_buffer_size: Тази директива задава размера на буфера за тялото на заявката. Ако планирате да стартирате уеб сървъра на 64-битови системи, трябва да зададете стойността на 16k. Ако искате да стартирате уеб сървъра на 32-битовата система, задайте стойността на 8k.

client_max_body_size: Ако възнамерявате да обработвате големи качвания на файлове, трябва да зададете тази директива на поне 2 m или повече. По подразбиране е зададено на 1м.

client_body_in_file_only: Ако сте деактивирали директивата client_body_buffer_size със символа на хештег # и тази директива client_body_in_file_only е зададена, Nginx ще запише буфери за заявки във временен файл. Това не се препоръчва за производствена среда.

client_body_in_single_buffer: Понякога не цялото тяло на заявката се съхранява в буфер. Останалата част от него се записва или записва във временен файл. Ако обаче възнамерявате да запазите или съхраните пълния буфер на заявка в един буфер, трябва да активирате тази директива.

client_header_buffer_size: Можете да използвате тази директива, за да зададете или разпределите буфер за заглавките на заявките. Можете да зададете тази стойност на 1m.

big_client_header_buffers: Тази директива се използва за определяне на максимален брой и размер за четене на големи заглавки на заявки. Можете да зададете максималния брой и размер на буфера на 4 и 8k точно.

компресия

Компресирането на обема на данни, прехвърлени по мрежата, е друг начин да гарантирате, че вашият уеб сървър ще работи по-добре. В този раздел ще използваме директиви като gzip, gzip_comp_level и gzip_min_length за компресиране на данни.

Поставете следния код в секцията http, както е показано по-долу:

http {

gzip на;
gzip_comp_level 2;
gzip_min_length 1000;
gzip_types text / xml text / css;
gzip_http_version 1.1;
gzip_vary на;
gzip_disable "MSIE [4-6] \.";

}

gzip: Ако искате да активирате компресията, включете стойността на тази директива. По подразбиране той е деактивиран.

gzip_comp_level: Можете да използвате тази директива, за да зададете ниво на компресия. За да не губите ресурси на процесора, не е необходимо да задавате нивото на компресия твърде високо. Между 1 и 9 можете да зададете нивото на компресия на 2 или 3.

gzip_min_length: Задайте минималната дължина на отговора за компресия чрез полето заглавие на отговора на съдържанието. Можете да го зададете на повече от 20 байта.

gzip_types: Тази директива ви позволява да изберете типа отговор, който искате да компресирате. По подразбиране текстът / html на типа отговор винаги се компресира. Можете да добавите друг тип отговор, като текст / css, както е показано в кода по-горе.

gzip_http_version: Тази директива ви позволява да изберете минималната HTTP версия на заявка за компресиран отговор. Можете да използвате стойността по подразбиране, която е 1,1.

gzip_vary: Когато gzip директива е активирана, тази директива добавя полето заглавие Vary: Accept Encoding към отговора.

gzip_disabled: Някои браузъри като Internet Explorer 6 нямат поддръжка за компресия на gzip. Тази директива използва полето за заглавие на потребителски агент, за да деактивира компресията за определени браузъри.

кеширане

Използвайте функции за кеширане, за да намалите броя пъти за зареждане на едни и същи данни няколко пъти. Nginx предоставя функции за кеширане на метаданни със статично съдържание чрез директива open_file_cache.

Можете да поставите тази директива в секцията сървър, местоположение и http.

http {

open_file_cache max = 1000 неактивни = 30s;
open_file_cache_valid 30s;
open_file_cache_min_uses 4;
open_file_cache_errors on;

}

open_file_cache: Тази директива е деактивирана по подразбиране. Активирайте го, ако искате да внедрите кеширане в Nginx. Тази директива съхранява метаданни на файлове и директории, обикновено поискани от потребителите.

open_file_cache_valid: Тази директива съдържа информация за архивиране вътре в директивата open_file_cache. Можете да използвате тази директива, за да зададете валиден период обикновено за секунди, след което информацията, свързана с файлове и директории, отново се валидира.

open_file_cache_min_uses: Nginx обикновено изчиства информация вътре в директивата open_file_cache след период на неактивност въз основа на open_file_cache_min_uses. Можете да използвате тази директива, за да зададете минимален брой достъп, за да идентифицирате до кои файлове и директории се осъществява активно достъп.

open_file_cache_errors: Можете да използвате тази директива, за да разрешите на Nginx да кешира грешки като „разрешение отказано“ или „не може да има достъп до този файл“, когато файловете са достъпни. Така всеки път, когато достъпът до ресурс е от потребител, който няма право да го прави, Nginx показва същия доклад за грешка „разрешение е отказано“.

Timeout

Конфигурирайте времето за изчакване с помощта на директиви като keepalive_timeout и keepalive_requests, за да предотвратите загубата на дълго чакащи връзки.

В секцията HTTP копирайте и поставете следния код:

http {

keepalive_timeout 30s;
keepalive_requests 30;
send_timeout 30s;

}

keepalive_timeout: Поддържайте живите връзки за около 30 секунди. По подразбиране е 75 секунди.

keepalive_requests: Конфигурирайте редица заявки, за да останете живи за определен период от време. Можете да зададете броя на заявките на 20 или 30.

keepalive_disable: ако искате да деактивирате keepalive връзка за конкретна група браузъри, използвайте тази директива.

send_timeout: Задайте изчакване за предаване на данни на клиента.

Конфигурация на сигурността за Nginx

Следващите се фокусират единствено върху това как да конфигурирате сигурно Nginx вместо уеб приложение. По този начин няма да разглеждаме уеб-базирани атаки като SQL инжекция и т.н..

В този раздел ще разгледаме как да конфигурирате следното:

  • Ограничете достъпа до файлове и директории
  • Конфигурирайте регистрационни файлове, за да следите злонамерените дейности
  • Предотвратяване на DDoS
  • Деактивиране на списъка с директории

Ограничете достъпа до файлове и директории

Нека разгледаме как да ограничим достъпа до чувствителни файлове и директории чрез следните методи.

Чрез използване на HTTP удостоверяване

Можем да ограничим достъпа до чувствителни файлове или области, които не са предназначени за обществено гледане, като поискаме удостоверяване от потребители или дори администратори. Изпълнете следната команда, за да инсталирате помощна програма за създаване на файл с парола, ако не сте я инсталирали.

apt-get install -y apache-utils

След това създайте файл с парола и потребител с помощта на htpasswd инструмента, както е показано по-долу. Инструментът htpasswd се предоставя от помощната програма apache2-utils.

sudo htpasswd -c / etc / apache2 / .htpasswd микрофон

Можете да потвърдите дали успешно сте създали потребителска и произволна парола чрез следната команда

котка и т.н. / apache2 / .htpasswd

В секцията за местоположение можете да поставите следния код, за да подканите потребителите за удостоверяване с помощта на директивата auth_basic.

местоположение / администратор {

basic_auth "Административна зона";
auth_basic_user_file / и т.н. / apache2 / .htpasswd;

}

Използвайки директивата Allow

В допълнение към директивата basic_auth, можем да използваме директивата за разрешаване, за да ограничим достъпа.

В секцията за местоположение можете да използвате следния код, за да разрешите на посочените IP адреси да влязат в чувствителна зона.

местоположение / администратор {
позволяват 192.168.34.12;
разрешава 192.168.12.34;
}

Конфигурирайте регистрационни файлове, за да следите злонамерени дейности

В този раздел ще конфигурираме регистрационни файлове за грешки и достъп, за да следим конкретно валидни и невалидни заявки. Можете да разгледате тези регистрационни файлове, за да разберете кой е влязъл в определен момент или кой потребител е получил достъп до определен файл и т.н..

error_log: Позволява ви да настроите логване към определен файл като syslog или stderr. Можете също да определите нивото на съобщенията за грешки, които искате да влезете.

access_log: Позволява да записва потребителска заявка във файла access.log

В HTTP секцията можете да използвате следното.

http {

access_log логове / access.log комбинирани;
error_log logs / warn.log предупреждават;

}

Предотвратяване на DDOS

Можете да защитите Nginx от DDOS атака по следните методи:

Ограничаване на заявките на потребителите 

Можете да използвате директивите limit_req_zone и limit_req, за да ограничите скоростта на заявка, изпратена от потребители за минути.

Добавете следния код в секцията за местоположение, вградена в секцията на сървъра.

limit_req_zone $ binary_remote_addr зона = един: 10m скорост = 30r / m;

сървър {
location /admin.html {
limit_req зона = една;
}

}

Ограничете броя на връзките 

Можете да използвате директивите limit_conn и limit_conn_zone, за да ограничите връзката до определени места или области. Например, кодът по-долу получава 15 връзки от клиенти за определен период.

Следващият код ще отиде в секцията за местоположение.

limit_conn_zone $ binary_remote_addr зона = addr: 10m;

сървър {

местоположение / продукти / {
limit_conn addr 10;

}
}

Прекъснете бавните връзки   

Можете да използвате директивите за изчакване, като client_body_timeout и client_header_timeout, за да контролирате колко дълго ще чака Nginx за писане от клиентското тяло и заглавката на клиента.

Добавете следното в секцията на сървъра.

сървър {
client_body_timeout 5s;
client_header_timeout 5s;
}

Също така би било добра идея да спрете DDoS атаките на ръба чрез използване на облачни базирани решения, както е споменато тук.

Деактивиране на списъка с директории

Можете да използвате директивата auto_index, за да предотвратите списъка с директории, както е показано в кода по-долу. Трябва да го зададете на изключена стойност, за да деактивирате списъка с директории.

местоположение / {
auto_index изключен;
}

заключение

Конфигурирахме уеб сървъра на Nginx, за да се представя ефективно и да го предпази от прекомерна злоупотреба в производствена среда. Ако използвате Nginx за уеб приложения, насочени към Интернет, тогава трябва да помислите и за използване на CDN и облачна защита за по-добра производителност и сигурност.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map