14. august 2009, kell 19:29

Nginxi seadistamine

• Nginx

Nginxi õige konfigureerimise teema on väga suur ja ma kardan, et see ei mahu ühe Habré artikli raamistikku. Selles tekstis püüdsin rääkida üldine struktuur config, huvitavamad pisiasjad ja üksikasjad võivad tulla hiljem. :)

Hea lähtepunkt nginxi seadistamiseks on distributsiooniga kaasas olev konfiguratsioon, kuid paljusid selle serveri võimalusi pole selles isegi mainitud. Palju rohkem üksikasjalik näide saadaval Igor Sysoevi veebisaidil: sysoev.ru/nginx/docs/example.html. Parem proovime siiski oma konfiguratsiooni ehitada nullist, bridži ja poetessidega. :)

Alustame sellest üldised seaded. Esiteks näitame kasutajat, kelle nimel nginx töötab (halb on rootina töötada, kõik teavad :))

Nüüd ütleme nginxile, mitu tööprotsessi tuleb luua. Tavaliselt, hea valik Mõnikord võrdub protsesside arv teie serveri protsessorituumade arvuga, kuid selle seadistusega tasub katsetada. Kui eeldatakse suurt koormust HDD, saate iga füüsilise kõvaketta jaoks teha ühe protsessi, kuna kogu tööd piirab ikkagi selle jõudlus.

Töötaja_protsessid 2;

Teeme selgeks, kuhu vealogid kirjutada. Siis üksikisiku jaoks virtuaalserverid, saab selle parameetri alistada, nii et selles logis kuvatakse ainult "globaalsed" vead, mis on seotud näiteks serveri käivitamisega.

Error_log /spool/logs/nginx/nginx.error_log teade; # Teavitamise taset saab loomulikult muuta

Nüüd tuleb väga huvitavate sündmuste jaotis. Selles saate määrata maksimaalne summaühendused, mida üks töötaja protsess samaaegselt töötleb, ja meetod, mida kasutatakse OS-i sündmuste kohta asünkroonsete teatiste saamiseks. Loomulikult saate valida ainult need meetodid, mis on teie OS-is saadaval ja kaasati kompileerimise ajal.

Need seaded võivad teie serveri jõudlust oluliselt mõjutada. Need tuleb valida ükshaaval, sõltuvalt OS-ist ja riistvarast. Võin anda vaid mõned üldised reeglid.

Sündmustega töötamise moodulid:
- valimine ja poll on tavaliselt aeglasemad ja koormavad protsessorit üsna tugevalt, kuid need on saadaval peaaegu kõikjal ja töötavad peaaegu alati;
- kqueue ja epoll - tõhusamad, kuid saadaval ainult FreeBSD ja Linux 2.6 jaoks;
- rtsig - ilus tõhus meetod, ja seda toetavad isegi väga vanad Linuxid, kuid see võib põhjustada probleeme suur numberühendused;
- /dev/poll - minu teada töötab see veidi rohkem eksootilised süsteemid, nagu Solaris, ja on selles üsna tõhus;

worker_connections parameeter:
- teenindatavate klientide maksimaalne koguarv on võrdne töötaja_protsessidega * töötaja_ühendustega;
- Mõnikord saavad nad sisse töötada positiivne pool isegi kõige äärmuslikumad väärtused, nagu 128 protsessi, 128 ühendust protsessi kohta või 1 protsess, kuid parameetriga worker_connections=16384. Viimasel juhul peate aga suure tõenäosusega OS-i häälestama.

Sündmused (
töötaja_ühendused 2048;
kasutada kqueue; # Meil ​​on BSD :)
}

Järgmine jaotis on suurim ja sisaldab kõige huvitavamaid asju. See on virtuaalserverite ja nende kõigi jaoks ühiste parameetrite kirjeldus. Ma jätan vahele standardseaded, mis on igas konfiguratsioonis, näiteks logide teed.

HTTP(
# Kogu allolev kood on selles jaotises %)
# ...
}

Selle jaotise sees võivad olla üsna huvitavad parameetrid.

Sendfile süsteemikutse on Linuxi jaoks suhteliselt uus. See võimaldab teil andmeid võrku saata, ilma et peaksite neid rakenduse aadressiruumi kopeerima. Paljudel juhtudel parandab see oluliselt serveri jõudlust, seega on kõige parem alati lubada suvand sendfile.

Selle eest vastutab parameeter keepalive_timeout maksimaalne aeg püsiühenduse säilitamine, kui kasutaja selle kaudu midagi ei taotle. Mõelge, kuidas teie sait päringuid saadab, ja kohandage seda seadet. AJAX-i aktiivselt kasutavate saitide puhul on parem hoida ühendust kauem staatiliste lehtede puhul, mida kasutajad pikka aega loevad, parem ühendus varakult katkestada. Pidage meeles, et kui säilitate passiivse ühenduse, loote ühenduse, mida saaks kasutada teisiti. :)

Keepalive_timeout 15;

Eraldi tasub esile tõsta nginxi puhverserveri sätted. Enamasti kasutatakse nginxi täpselt puhverserverina, seega on neil üsna suur tähtsus. Eelkõige on mõistlik määrata puhverserveri taotluste puhvri suurus vähemalt taustaserveri eeldatava vastuse suurus. Aeglaste (või vastupidi väga kiirete) taustaprogrammide puhul on mõistlik muuta taustaprogrammi vastuse ootamise ajalõppe. Pidage meeles, et mida pikemad need ajalõpud on, seda kauem ootavad teie kasutajad vastust, kui taustaprogramm on aeglane.

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

Väike trikk. Kui nginx teenindab rohkem kui ühte virtuaalset hosti, on mõttekas luua vaikimisi virtuaalne host, mis töötleb päringuid juhtudel, kui server ei leia muud alternatiivi, kasutades kliendipäringu hosti päist.

# vaikimisi virtuaalne host
server(
kuula 80 vaikimisi;
serveri_nimi localhost;
keelata kõik;
}

Sellele võib järgneda üks (või mitu) "serveri" sektsiooni. Igaüks neist kirjeldab virtuaalset hosti (enamasti nimepõhist). Ühe hostimise paljude saitide omanike või hostijate jaoks võib olla midagi sellist, nagu direktiiv

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

Ülejäänud kirjeldavad suure tõenäosusega oma virtuaalset hosti otse põhikonfiguratsioonis.

Server (
kuula 80;

# Pange tähele, et server_name direktiiv võib määrata mitu nime korraga.
serveri_nimi myserver.ru myserver.com;
access_log /spool/logs/nginx/myserver.access_log ajastatud;
error_log /spool/logs/nginx/myserver.error_log warn;
# ...

Määrame väljundi vaikekodeeringu.

Charset utf-8;

Ja oletame, et me ei taha vastu võtta klientide päringuid, mis on pikemad kui 1 megabaid.

Client_max_body_size 1m;

Lubame serveris SSI ja palume reserveerida SSI muutujate jaoks mitte rohkem kui 1 kilobait.

Si on;
ssi_väärtuse_pikkus 1024;

Ja lõpuks kirjeldame kahte asukohta, millest üks viib taustaprogrammi, Apache'i, mis töötab pordis 9999, ja teine ​​saadab staatilisi pilte kohalikust failisüsteem. Kahe asukoha puhul on sellel vähe mõtet, kuid suurema hulga jaoks on mõttekas ka kohe defineerida muutuja, kuhu serveri juurkataloogi salvestatakse, ja seejärel kasutada seda asukohakirjeldustes.

võrk Nginxi server on üks populaarsemaid veebiservereid väga suure jõudlusega ja kiire töötlemine staatilised päringud kasutajatelt. Õige konfiguratsiooniga saavutate selle veebiserveri väga suure jõudluse. Nginx on staatiliste failide käsitlemisel väga kiire, olgu see siis html lehekülgi või muud tüüpi ressursse.

Ühes eelmistest artiklitest vaatlesime juba selle peamiste parameetrite seadistamist, selles artiklis tahan pikemalt peatuda veebiserveri jõudlusel ja ettevalmistamisel lahingutingimustes kasutamiseks. Mis puudutab Linuxi levitamine, siis täna kaalume CentOS-i, seda süsteemi kasutatakse sageli serverites ja Nginxi seadistamisel võib tekkida raskusi. Järgmisena vaatleme Nginx CentOS-i seadistamist, räägime sellest, kuidas lubada http2 täielik tugi, google pagespeed ja konfigureerige põhikonfiguratsioonifail.

Ametlikud CentOS-i hoidlad sisaldavad Nginxi ja tõenäoliselt on see teie süsteemi juba installitud. Kuid me tahame, et sait töötaks HTTP2-protokolli abil, mis võimaldab teil kõik andmed ühe ühendusega edastada, ja see suurendab jõudlust. http2 kaudu töötamiseks peate konfigureerima SSL-sertifikaat, kuid see on juba kirjas Lets Encrypt Nginxi sertifikaadi hankimise artiklis. Kuid see pole veel kõik. Tavalise SSL-ilt HTTP2.0-le üleminekuks kasutab enamik brausereid nüüd ALPN-protokolli ja seda toetatakse alates versioonist OpenSSL 1.02. Kuigi hoidlates on ainult OpenSSL 1.01. Seetõttu peame installima OpenSSL 1.02-ga ehitatud Nginxi versiooni. Selleks saate kasutada Broken Repot:

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

Kui kasutate EPEL-i hoidlat, peate märkima, et te ei pea Nginxi sellest võtma:

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

Nüüd Nginxi õige versiooni installimiseks tippige lihtsalt:

sudo yum installige nginx

Kõige Uusim versioon Nginx 1.13.2 täieliku ALPN-toega. Järgmisena liigume häälestuse juurde.

2. Nginxi seadistamine

Esimene samm on kaaluda konfiguratsioonifaili struktuuri. Esmapilgul võib siin kõik tunduda väga segane, kuid kõik on üsna loogiline:

globaalsed valikud
sündmused ()
http(
server(
asukoht ()
}
server ()
}

Esiteks on globaalsed valikud, mis määravad programmi põhiparameetrid, näiteks, millise kasutajana see käivitatakse ja protsesside arvu. Järgmine on sektsioon sündmused, mis kirjeldab, kuidas Nginx sissetulevatele ühendustele reageerib, millele järgneb jaotis http, mis ühendab kõik tööga seotud seaded http protokoll. See sisaldab jaotist server, vastutab iga selline sektsioon eraldi domeeni eest, serverijaotis sisaldab sektsioone asukoht, millest igaüks vastutab konkreetse eest Taotlege URL-i, pange tähele, et see ei ole serveris olev fail, nagu Apache'is, vaid päringu URL.

Põhiline globaalsed seaded teeme seda failis /etc/nginx/nginx.conf. Järgmisena vaatame, mida täpselt muudame ja milliseid väärtusi on soovitatav määrata. Alustame globaalsetest valikutest:

• kasutaja- kasutaja, kelle nimel server käivitatakse, peab olema saidifailidega kataloogi omanik ja tema nimel tuleb käivitada php-fpm;
• töötaja_protsessid- käivitatavate Nginxi protsesside arv tuleb määrata täpselt nii palju kui teil on tuumasid, näiteks minul on 4;
• worker_cpu_affinity- see parameeter võimaldab määrata iga protsessi eraldi protsessori tuumale, et programm ise valiks, mille külge kinnitada;
• worker_rlimit_nofile- maksimaalne failide arv, mida programm saab avada, iga ühenduse jaoks on vaja vähemalt kahte faili ja igal protsessil on teie määratud arv ühendusi, seega on valem: töötaja_protsessid * töötaja_ühendused * 2, parameeter töötaja_ühendused Vaatame seda allpool;
• pcre_jit- lubage see suvand töötlemise kiirendamiseks regulaaravaldised JIT-i koostamise kasutamine;

Sündmuste jaotises peaksite konfigureerima kaks parameetrit:

• töötaja_ühendused- ühe protsessi ühenduste arv peab olema piisav sissetulevate ühenduste töötlemiseks. Esiteks peame teadma, kui palju neid sissetulevaid ühendusi on, selleks vaatame statistikat serveris ip_address/nginx_status. Vaatame allpool, kuidas see lubada. Real Active Connections näeme aktiivsete ühenduste arvu serveriga, samuti peame arvestama, et loendatakse ka php-fpm-iga ühendusi. Järgmisena pöörake tähelepanu aktsepteeritud ja käsitletud väljadele, esimene kuvab töödeldud ühendused, teine ​​- aktsepteeritud ühenduste arv. Väärtused peavad olema samad. Kui need erinevad, tähendab see, et ühendusi pole piisavalt. Vaata näiteid, esimene pilt on probleem, teine ​​on järjekord. Minu konfiguratsiooni jaoks võib optimaalne arv olla 200 ühendust (kokku 800, võttes arvesse 4 protsessi):

• multi_accept- võimaldab programmil vastu võtta mitu ühendust korraga, samuti kiirendab tööd suure hulga ühendustega;
• aktsepteeri_mutex- seadke selle parameetri väärtuseks välja, et kõik protsessid saaksid kohe teate uute ühenduste kohta;

Sündmuste jaotises on soovitatav kasutada ka käsku use epoll, kuna see on Linuxi jaoks kõige tõhusam meetod sissetulevate ühenduste töötlemiseks, kuid seda meetodit kasutatakse vaikimisi, nii et ma ei näe mõtet seda käsitsi lisada. Vaatame veel mõnda parameetrit http-jaotusest:

• saada fail- kasutage sendfile andmete saatmise meetodit. Kõige tõhusam meetod Linuxi jaoks.
• tcp_nodelay, tcp_nopush- saadab päringu päised ja keha ühes paketis, töötab veidi kiiremini;
• Keepalive_timeout- kliendiga ühenduse säilitamise ajalõpp, kui teil pole väga aeglaseid skripte, siis piisab 10 sekundist, määrake väärtus nii kaua, kui vaja, et kasutaja saaks serveriga ühenduse luua;
• reset_timedout_connection- katkestada ühendused pärast ajalõpu.
• open_file_cache- vahemälu teave failid avada. Näiteks open_file_cache max=200000 inactive=120s; max - maksimaalne failide arv vahemälus, vahemällu salvestamise aeg.
• open_file_cache_valid- kui peate kontrollima failide asjakohasust. Näiteks: open_file_cache_valid 120s;
• open_file_cache_min_uses- salvestage vahemällu ainult need failid, mis on avatud määratud arv kordi;
• open_file_cache_errors- mäleta faili avamise vigu.
• kui_modifitseeritud_alates- määrab, kuidas if-modified-sine päiseid töödeldakse. Selle päise abil saab brauser saada 304 vastuse, kui leht pole sellest ajast peale muutunud viimati vaadatud. Võimalikud valikud: ära saada – ära, saada, kui kellaaeg täpselt klapib – täpne, saada, kui kellaaeg kattub täpselt või rohkem – enne;

See näeb välja selline nginxi seadistus conf:

kasutaja nginx;
töötaja_protsessid 4;
worker_cpu_affinity auto;
töötaja_rlimit_nofile 10000;
pcre_jit on;

error_log /var/log/nginx/error.log hoiatus;
load_module "moodulid/ngx_pagespeed.so";

sündmused (
multi_accept sees;
aktsepteeri_mutex väljas;
töötaja_ühendused 1024;
}

saatmisfail sees;
tcp_nopush sees;
tcp_nodelay sees;

avatud_faili_vahemälu max=200000 passiivne=20s;
open_file_cache_valid 120s;
open_file_cache_errors on;

reset_timedout_connection on;
client_body_timeout 10;
Keepalive_timeout 65;

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

3. http2 seadistamine

Ma ei kirjelda üksikasjalikult serveri jaotise seadistamist, sest tegin seda juba artiklis Nginxi installimise kohta Ubuntus ja mul pole siin midagi lisada, SSL-i seadistamine See on üsna lai teema ja seda käsitletakse ka eraldi artiklis. Kuid http2 konfigureerimiseks peab teil juba olema SSL. Järgmisena kohandage lihtsalt oma serveri jaotises kuulamisjuhist:

kuula 194.67.215.125:443 vaikeserver;

kuula 194.67.215.125:443 http2 vaikeserver;

Nagu nii lihtsal viisil saate http2 lubada, kui olete selle varem installinud õige versioon Nginx.

4. PageSpeedi seadistamine

Google Pagespeed on Nginxi moodul, mis teostab erinevaid optimeerimisi, et tagada lehtede kiirem laadimine, veebiserveri tõhusam töö ja kasutajate vähem ebamugavustunne. See hõlmab vahemällu salvestamist, optimeerimist html kood, pildi optimeerimine, javascripti liitmine Ja css kood ja palju muud. Seda kõike tehakse Nginxi tasemel, seega on see tõhusam kui PHP-s. Kuid on üks puudus: moodul eemaldab päise Viimati muudetud.

Fakt on see, et PageSpeed ​​​​määrab kõigi failide jaoks väga pika vahemälu rea ja lisab failinimele selle räsi. Nii on ressursside laadimise kiirus palju suurem, kuna brauser taotleb ainult uue räsiga faile ja LastModified eemaldatakse, et kasutajad näeksid muudatusi, kui mõnda faili muudetakse. Nüüd vaatame, kuidas moodulit installida. Peame selle lähtekoodist üles ehitama.

Esmalt installige monteerimistööriistad, see on väga oluline, kui te seda ei installi, kuvatakse tõrge ja te ei tea, mida teha:

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

Laadige alla ja ekstraktige oma versiooni jaoks Nginxi allikad, näiteks 1.13.3:

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

Nginxi serveri seadistamine ei hõlma programmi uuesti kokkupanemist ja asendamist hoidlast, me lihtsalt kasutame neid allikaid mooduli koostamiseks. Laadige alla ja eraldage PageSpeedi allikad:

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

Laadige alla ja pakkige PageSpeedi optimeerimise teek lahti mooduli allikatega kausta:

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

Laadige alla ja pakkige lahti OpenSSL 1.02 allikad:

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

Nüüd peame mooduli kokku panema. Esiteks vaadake võimalusi, millega praegune Nginx on ehitatud:

Nüüd läheme Nginxiga kausta, asendame kõik saadud suvandid, suvand --add-dynamic-module PageSpeedi jaoks, OpenSSL ja proovime ehitada:

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_tube_module --with_module --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_prereread_module --with-cc-opt="- O2 -g -pipe -Sein -Wp,-D_FORTIFY_SOURCE=2 -erandid -fstack-protector-strong -param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=üldine" --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)
# tegema

Kui kõik oli õigesti tehtud, saate väljundis kausta obj mooduli ngx_pagespeed.so, peate selle kopeerima kausta /etc/nginx/modules:

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

Looge vahemälu jaoks kaust:

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

Nüüd lisage mooduli lubamiseks failis /etc/nginx/nginx.conf järgmine rida:

load_module "modules/ngx_pagespeed.so";

Üks populaarsemaid veebiservereid

Nginx on oma jõudluse tõttu veebi- ja puhverserveri kasutajate seas väga populaarne. Serveril on palju eeliseid, kuid selle seadistamine on algajale keeruline. Soovime aidata teil mõista konfiguratsioonifaile, süntaksit ja põhilisi Nginxi parameetreid.

Kataloogide hierarhia

Kõik serveri konfiguratsioonifailid asuvad kataloogis /etc/nginx. Lisaks on kataloogi sees veel mitu kausta, samuti modulaarsed konfiguratsioonifailid.

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/

Kui olete Apache'i kasutanud, peaksite olema kursis saitide lubatud ja saadaolevate saitide kataloogidega. Need määravad saitide konfiguratsiooni. Loodud failid salvestatakse viimasesse kataloogi. Saitide toega kausta on vaja ainult konfiguratsioonide salvestamiseks aktiveeritud lehed. Nende linkimiseks vajate kaustade vahel sümboolset linki. Seadistused saab salvestada ka kataloogi conf.d. Samal ajal loetakse Nginxi käivitamisel uuesti iga .conf-laiendiga fail. Konfiguratsioonifailide kirjutamisel tippige kood ilma vigadeta ja järgige süntaksit. Kõik muud failid asuvad kaustas /etc/nginx. Konfiguraator sisaldab teavet konkreetsete protsesside ja lisakomponentide kohta.

Peamine Nginxi konfiguratsioonifail on nginx.conf.

See loeb kõiki konfiguratsioonifaile, ühendades need üheks, mida küsitakse serveri käivitumisel. Ava fail koos:

sudo nano /etc/nginx/nginx.conf

Ekraanile ilmuvad järgmised read:

kasutaja www-andmed;
töötaja_protsessid 4;
pid /var/run/nginx.pid;
sündmused (
töötaja_ühendused 768;
#multi_accept on;
}
http (
. . .

Esimene on Üldine informatsioon Nginxi kohta. Fraas user www-data tähistab kasutajat, kes serverit käitab. PID-direktiiv näitab, kuhu PID-protsessid mõeldud on sisemine kasutamine. Rida worker_processes näitab, kui palju protsesse saab Nginx samaaegselt käivitada. Lisaks saab siin määrata logisid (nt vealogi määratakse vea_logi direktiivi abil). Allpool on sündmuste jaotis. See on vajalik serveriühenduste haldamiseks. Pärast seda on http-plokk.

Nginxi konfiguratsioonifaili struktuur

Failivormingu struktuuri mõistmine aitab teil paremini mõista oma veebiserveri konfiguratsiooni. See on jagatud struktuuriplokkideks. http-ploki konfiguratsiooni üksikasjad on kihistatud privaatplokkide abil. Nad pärivad omadused vanemalt, s.t. see, kus nad asuvad. See plokk salvestab enamiku serveri konfiguratsioonidest. Need on jagatud serveriplokkideks, millise asukoha sees.

Nginxi serveri konfigureerimisel pidage meeles, et mida madalam on konfiguratsiooniplokk, seda vähem elemente pärib omadused ja vastupidi. Fail sisaldab suurt hulka valikuid, mis muudavad serveri tööd. Saate määrata näiteks kliendile saadetud failide tihendamise. Selleks sisestage parameetrid:

gzip sees;
gzip_disable "msie6";

Pange tähele, et sama parameeter võib võtta erinevaid tähendusi V erinevad plokid. Esmalt määrake see ülaosas, seejärel määrake parameeter soovitud tasemel uuesti. Kui viimane tegevus ei käivitata, määrab programm väärtused automaatselt.

Faili nginx.conf viimased read on:

sisaldab /etc/nginx/conf.d/*.conf;
sisaldab /etc/nginx/sites-enabled/*;

Need näitavad, et asukoht ja serveriplokid on salvestatud väljaspool seda faili. Need määravad URL-ide ja konkreetsete failide seaded. See struktuur on vajalik modulaarse konfiguratsioonistruktuuri säilitamiseks. Selle sees saate luua uusi katalooge ja faile erinevate saitide jaoks. Pealegi, sarnased failid saate rühmitada. Pärast kaalumist saate faili nginx.conf sulgeda.

Virtuaalsed plokid

Need on analoogsed Apache'i virtuaalsete hostidega. Serveri sektsiooni plokid sisaldavad serveris asuvate üksikute saitide omadusi. Kaustas Saidid-saadaval leiate vaikimisi serveriploki faili. Selle seest leiate vajalikud andmed, mida võib saitide hooldamisel vaja minna.

CD-saidid-saadaval
sudo nano vaikimisi
server(
juur /usr/share/nginx/www;
indeks indeks.html index.htm;
serveri_nimi localhost;
asukoht/(
proovi_failid $uri $uri/ /index.html;
}
asukoht /doc/ (
alias /usr/share/doc/;
autoindeks sisse lülitatud;
luba 127.0.0.1;
keelata kõik;
}
}

Ülaltoodud näites eemaldati kommentaarid tahtlikult. Seda tehti tajumise hõlbustamiseks. Serveriplokkide sees on sätted, mis on suletud sulgudes:

See plokk paigutatakse faili nginx.conf kirjutatud http-i lõppu kaasamise direktiivi abil. Juurdirektiiv määratleb kataloogi, kus saidi sisu asub. Selles otsib programm faile, mida kasutaja taotleb. Vaikimisi tee on: /usr/share/nginx/www. Nginx eraldab read või direktiivid üksteisest semikoolonite abil. Kui te kirjavahemärki ei pane, loetakse mitu rida ühena. Indeksina kasutatavate reeglite määramiseks kasutage indeksi käskkirja. Server kontrollib neid loetletud järjekorras. Kui kasutaja ei taotlenud ühtegi saadaolevatest lehtedest, tagastatakse index.html. Kui seda pole, otsib server faili index.htm.

serveri_nime reegel

See sisaldab domeeninimede loendit, mida serveriplokk peab töötlema. Saate sisestada suvalise arvu neid tühikutega eraldatuna. Kui panete * domeeni lõppu või algusesse, saate nime määrata maskiga. Tärn vastab osa nimele. Kui sisestate *.com.ua, sisaldab see kõiki määratud aadresse domeeni tsoon. Kui aadress vastab mitme direktiivi kirjeldusele, vastab see täielikult sellele, mis vastab täielikult. Kui vasteid pole, on vastus kõige rohkem pikk nimi, kellel on mask. Vastasel juhul viiakse läbi regulaaravaldise sobitamine. Regulaaravaldisi kasutavad serverinimed algavad tildemärgiga (~).

Asukoha plokid

Järgmisena on meil asukohaplokk. See on vajalik töötlemismeetodi kindlaksmääramiseks teatud taotlusi. Kui ressursid ei ühti ühegi teise asukohaplokiga, rakendatakse neile sulgudes määratud käske. Need plokid võivad sisaldada teed nagu /doc/. uri ja asukoha täieliku vastavuse loomiseks kasutatakse = märki. Tilde abil saate regulaaravaldisi sobitada. Saate määrata ka tõstutundlikkuse, pannes ~. Kui lisate tärni, pole suurtäht oluline.

Pidage meeles: kui päring vastab täielikult asukohaplokile, kasutatakse seda ja otsing peatub. Kui sobivus on mittetäielik, võrreldakse URI-d asukohadirektiivide parameetritega. Kasutage ploki valimiseks plokki, mille ^~ vastab URI-le. Kui see valik pole lubatud, valib server optimaalse vaste ja teostab ka otsingu regulaaravaldiste abil. See on vajalik ühe sobiva malli valimiseks. Kui leitakse sobiv väljend, kasutatakse seda. Vastasel juhul rakendatakse eelmist URI vastet. Kuid pidage meeles, et Nginx eelistab täismänge. Kui neid seal pole, hakkab see otsima regulaaravaldisi ja seejärel URI järgi. Otsingupaarsus määratakse sümbolikombinatsiooniga ^~.

try_files reegel

See on väga kasulik tööriist, mis suudab kontrollida failide olemasolu ettenähtud korras. See kasutab päringu töötlemiseks esimest, mis vastab kriteeriumidele. sa võid kasutada Lisavalikud et määrata, kuidas server päringuid teenindab. Konfiguraatoril on see vaikimisi rida:

proovi_failid $uri $uri/ /index.html;

Mida see tähendab? Kui saabub päring, mida teenindab asukohaplokk, proovib server esmalt käsitleda uri-d failina. Selle annab muutuja $uri. Kui vasteid pole, käsitletakse uri-d kataloogina. Selle olemasolu saate kontrollida, lisades lõpu kaldkriipsu: $uri/. On olukordi, kus ei faili ega kataloogi ei leita. Sel juhul laaditakse vaikimisi fail - index.html. Reegel try_files kasutab viimast parameetrit tagavarana. Sellepärast see fail peab olema süsteemis. Kui aga vasteid üldse ei leita, tagastab Nginx vealehe. Selle määramiseks sisestage = ja veakood:

Lisavalikud

Kui rakendate pseudonüümireeglit, saate näiteks asukohaploki lehti teenindada väljaspool juurkataloogi. Kui on vaja doc-faile, küsitakse neid kaustast /usr/share/doc/. Lisaks alustab automaatse indekseerimise reegel määratud asukohadirektiivi serverikataloogide loendit. Kui kirjutate keelamise ja lubamise read, saate muuta juurdepääsu kataloogidele.

Kokkuvõtteks tasub öelda, et Nginx on väga võimas multifunktsionaalne tööriist. Kuid selle tööpõhimõtte hästi mõistmiseks kulub aega ja vaeva. Kui saate aru, kuidas konfiguratsioonid töötavad, saate täielikult nautida programmi kõiki funktsioone.

Tere, Hea kasutaja Habrakhabra. Minu jutt tuleb sellest, kuidas operatsioonisaalis kohalike veebiarendusprojektide jaoks pinnast ette valmistada Ubuntu süsteem 16.04.1 LTS.

Selles artiklis tahaksin hajutada ja selgitada võimalikud raskused mis on seotud vajaliku tarkvara installimise ja konfigureerimisega kaasaegne veebiarendus, millega algajad arendajad võivad kokku puutuda ja mitte ainult.

Tehnoloogiad, mida artiklis kasutatakse: nginx, php-fpm.

Enne loo alustamist tahan märkida, et tegin kõik need toimingud "palja" süsteemiga.
Ma töötan koos aptitude pakettide halduriga. Samuti soovitan enne tarkvara installimist uuendada paketiindeksit ja pakette ennast. Selles artiklis teeme need sammud koos.

Mine!

Paketihalduri installimine sobivus, indeksi ja paketi värskendused

Installige:

Sudo apt install aptitude
Uuendame indeksit.

Sudo sobivuse värskendus
Uuendame pakette (käsk värskendab kõiki pakette, mille jaoks on uued versioonid; kui pakette on vaja eemaldada, siis seda tehakse).

Sudo aptitude täielik täiendus

Paigaldamine ja seadistamine nginx(versioon >= 1.10.0)

Paigaldame.

Sudo aptitude installige nginx
Käivitame.

Sudo teenuse nginx algus
Kontrollime versiooni, veendumaks, et me pole installinud vana, st madalamat kui 1.10.0.

Installimine ja käivitamine on lõpule viidud, nüüd läheme kataloogi, kuhu meie nginx on installitud, ja vaatame selle struktuuri. Nginxi kataloog asub sellel teel:

CD /etc/nginx/
Kataloogi sisu saab vaadata käsuga ls lippudega -la on kataloogi sisu vaatamine mugavam (tegelikult saab seda konkreetsete lippudega käsku täpsemalt ja täpsemalt kirjeldada, kuid; meil on täna teine ​​teema).

Ls-la
Oleme huvitatud Sel hetkel kaks kataloogi, mida ekraanipildil näete. Need on saitide jaoks saadaolevad ja saitide lubatud kataloogid.

Läheme saadaolevate saitide kataloogi ja alustame oma virtuaalse hosti (saidi) seadistamist.

CD /etc/nginx/sites-available
Enne konfiguratsioonifaili loomise alustamist kontrollime, mis meil on see kataloog. Minu puhul pole kataloog tühi, see sisaldab juba konfiguratsioonifaile, kustutasin need, et mitte eksitada.

Oluline kõrvalekalle

Kui installite nginxi "nullist", täpselt "nullist", alates nginxi desinstallimisest käsuga
sudo apt-get eemalda nginx või sudo apt eemalda nginxi konfiguratsioonifailid jäävad alles ja kui sa äkki ei saa aru, miks nginx ei tööta ja soovid selle uuesti installida (tavaliselt kasutavad seda algajad Linuxi kasutajad), siis isegi pärast uuesti installimist ei tööta see õigesti, kuna vanad konfiguratsioonifailid (neid ei kustutata pärast eemaldamist käsuga eemaldada) sisaldavad valesid sätteid, need tuleb kustutada või õigesti seadistada, alles siis töötab nginx.

Soovitan kustutada käsuga sudo apt-get purge nginx või sudo apt purge nginx. Kui kasutate paketihaldur sobivus siis sudo käsk aptitude purge nginx eemaldab kogu paketi koos kõigi sõltuvuste ja konfiguratsioonifailidega.

Vaikimisi on selles kataloogis üks fail, mida nimetatakse vaikimisi. See sisaldab näitega konfiguratsioonifaili koos kommentaaridega, saate seda vabal ajal uurida või täielikult kustutada (saate alati vaadata ametlikku dokumentatsiooni).

Ls-la

Loome oma konfiguratsioonifaili, mis vastab meie kohaliku saidi domeeninimele (või päris domeeninimele, kui te juba teate selle nime). See on mugav, kuna tulevikus, kui konfiguratsioonifaile on palju, säästab see teid nendes segaduse eest. Minu jaoks kannab see fail nime project.local.

Sudo touch project.local
Vaatame, mis juhtus.

Nüüd avame selle redaktoris, ma avan selle nanos.

Sudo nano projekt.kohalik
Näeme, et see on tühi. Liigume nüüd oma faili loomise juurde. Peate viima konfiguratsiooni vormile, nagu allpool kirjutatud. Kirjeldan ainult selle faili olulisi juhiseid, ülejäänuid ma ei kirjelda, kuna see pole hetkel oluline, meil on ju teema põhiseaded. Nendest "slaidi" sätetest piisab, et arendada kohapeal projekte, mitte ainult väikeseid, vaid ka üsna suuri. Järgmistes artiklites kirjeldan eraldi iga selle faili kasutatavat direktiivi (nii nimetatakse ridu, näiteks serveri_nimi).

Vaadake kommentaare otse aadressil konfiguratsioonifail.

Server ( kuula 80; # pordi kuulamine saidil nginx server_name project.local; # Domeeninimi vooluga seotud virtuaalne host root /home/stavanger/code/project.local; # kataloog, kus projekt asub, sisenemispunkti tee indeks index.php; # add_header Access-Control-Allow-Origin *; # serveeri staatilisi faile otse asukoht ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ ( access_log off; aegub max; logi_not_found off; ) asukoht / ( # add_header Access-Control-Allow- Origin *; try_files $uri $uri/ /index.php?$query_string ) asukoht ~* \.php$ ( try_files $uri = 404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix; :/var/run/php7.0-fpm.sock # ühendage pesa php-fpm fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name (de ~ /\ht);
Salvestage fail. Nüüd peame kontrollima, kas selles on vigu. Me saame seda teha meeskonnana.

Sudo nginx -t
Kui näeme sellist teavet nagu ekraanipildil, siis on kõik õige ja saame seadistamist jätkata. Kui näete tõrkeid, tasub konfiguratsioonifaili veel kord üle kontrollida.

Nüüd peame aktiveerima konfiguratsioonifaili, kataloogis /etc/nginx/sites-enabled/ peame looma sümboolse lingi (symbolic link). Kui installisite nginxi nullist, on selles kataloogis vaikefaili sümbol, mida arutati ülal, kui te seda ei vaja. Minge soovitud kataloogi.

CD /etc/nginx/sites-enabled/
Nüüd oleme sees soovitud kataloog. Loome oma sümboolika. Loomiseks kasutage käsku ln koos lipuga -s, seejärel näitame oma projekti.local config tee.

Sudo ln -s /etc/nginx/sites-available/project.local
Vaatame meie loodud sümlinki.

Veendumaks, et teeme kõike ikka õigesti, käivitame käsu uuesti.

Fail võõrustajad

See fail asub aadressil /etc/hosts. Kirjete olemasolu selles võimaldab teil käivitada nginxi, kasutades domeenina localhosti. Selles failis saate määrata alternatiivsed varjunimed, näiteks meie projekti project.local jaoks määrame domeeni project.local.

Avage fail nanoredaktoris.

Sudo nano /etc/hosts
Selles failis on muud teavet, lihtsalt ignoreerige seda. Peate lihtsalt lisama rea, nagu minu ekraanipildil.

Paigaldamine php-fpm (>=7.0)

sudo aptitude install php-fpm
Kontrollimine installitud versioon, igaks juhuks, kuigi Ubuntu 16.04.1-s on 7.0 versioon hoidlates.

Php-fpm7.0 -v

Teeme kindlaks, et kõik on korras. Alustame php-fpm.

Sudo teenuse php7.0-fpm algus
Kui muudate konfiguratsioone, ärge unustage deemonit taaskäivitada. See teeb nii. Aga me ei vaja seda.

Sudo teenuse php7.0-fpm taaskäivitamine
See on paigaldus ja php-fpm seadistus lõpetanud. Tõesti, see on kõik. See ei ole maagia; php-fpm pesa tee oli juba konfiguratsioonifailis määratud. Muidugi võib teil vaja minna php laiendused isiklike projektide arendamiseks, kuid saate neid vajadusel pakkuda.

Nüüd läheme oma projektiga kataloogi, mul on see sellel teel.

Cd /home/stavanger/code/project.local
Liigume ülaltoodud kataloogi ja teeme load 777 (st me teeme täielikud õigused kataloog meie projektiprojektiga.kohalik). See säästab meid tarbetute probleemide eest tulevikus.

Cd .. sudo chmod -R 777 projekt.kohalik
See lõpetab tarkvara seadistamise, loome oma töökataloogi project.local testfaili ja veendume, et kõik töötab. Loon selle sisuga faili index.php.

Me läheme brauserisse ja näeme, et kõik töötab meie jaoks suurepäraselt! PHP tõlk, sealhulgas.

Lugejate suhtes, Stavanger.

Spetsiaalne Nginxi-põhine veebiserver on suurepärane viis veebisaitide jõudluse parandamiseks. Sellel pole lihtsalt staatilise sisu töötlemise kiiruses võrdset: see talub hõlpsalt mitu tuhat samaaegset ühendust ning seda saab hõlpsasti optimeerida ja kohandada mis tahes konfiguratsiooniga. Kuid? Apache'i esiotsa toimiv nginx osutub kogu veebitaristu kõige haavatavamaks punktiks, seega tuleb erilist tähelepanu pöörata nginxi turvalisusele.

See artikkel on omamoodi haridusprogramm või, kui soovite, kokkuvõte kõigist nginxi turvalisuse parandamise tehnikatest. See ei sisalda teooriat, veebiserveri seadistamise põhitõdede kirjeldust ja muid asju. Selle asemel saate põhjaliku praktilise materjali, mis kirjeldab kõiki põhilisi samme, mida peate tõeliselt turvalise veebiserveri saamiseks tegema.

Paigaldamine

Nginxi pakett on saadaval eelkompileeritud kujul mis tahes levitamiseks. Ent serverit ise ehitades saate muuta selle kompaktsemaks ja töökindlamaks, samuti on teil võimalus muuta veebiserveri tervitusjoont, et rumalaid skriptilapsi peletada.

Muutke veebiserveri tervitusrida

Laadige alla nginxi allikad, avage fail src/http/ngx_http_header_filter_module.c ja leidke kaks järgmist rida:

static char ngx_http_server_string = "Server: nginx" CRLF;
static char ngx_http_server_full_string = "Server: " NGINX_VER CRLF;

Asendage need millegi sellisega:

static char ngx_http_server_string = "Server: ][ veebiserver" CRLF;
static char ngx_http_server_full_string = "Server: ][ veebiserver" CRLF;

Eemaldage kõik nginxi moodulid, mida te ei kasuta

Mõned nginxi moodulid loovad kompileerimise ajal otse veebiserveriga ühenduse ja kõik neist on potentsiaalsed ohud. Võib-olla leitakse tulevikus ühes neist haavatavus ja teie server on ohus. Mittevajalike moodulite keelamisega saate oluliselt vähendada sellise olukorra tekkimise ohtu.

Ehitage järgmiste käskude abil:

# ./configure --ilma-http_autoindex_module --ilma-http_ssi_moodulita
# tegema
# installige

Nii saad nginxi, mille SSI (Server Side Includes) ja Autoindexi moodulid on eelnevalt keelatud (ja enamikul juhtudel kasutu). Et teada saada, milliseid mooduleid saab veebiserverist turvaliselt eemaldada, käivitage konfigureerimisskript lipuga "-help".

Lahkame faili nginx.conf

Pärast installimist tuleks nginx konfigureerida. Seda protsessi kirjeldav materjal oli ajakirja lehekülgedel juba olemas, kuid jääme artikli teema juurde ja räägime serveri turvalisuse tõstmise võimalustest.

Keela serveri versiooni kuvamine kõigil vealehtedel

Lisage faili nginx.conf rida "server_tokens off". See sunnib nginxit peitma teavet veebiserveri tüübi ja versiooni kohta lehtedel, mis on loodud vastuseks kliendi ekslikule päringule.

Seadistage kaitse virna katkemise eest

Lisage serveri jaotisesse järgmised read:

# vi /etc/nginx/nginx.conf

# Maksimaalne puhvri suurus kliendipäringu keha salvestamiseks
kliendi_keha_puhvri_suurus 1K;
# Maksimaalne puhvri suurus kliendipäringute päiste salvestamiseks
kliendi_päise_puhvri_suurus 1k;
# Kliendipäringu keha maksimaalne suurus, mis on määratud päiseväljal Content-Length. Kui server peab toetama failide üleslaadimist, tuleb seda väärtust suurendada
kliendi_max_kere_suurus 1k;
# Suurte kliendipäringu päise lugemiseks mõeldud puhvrite arv ja suurus
suur_kliendi_päise_puhvrid 2 1k;

Pöörake tähelepanu direktiivile large_client_header_buffers. Vaikimisi eraldab nginx URI stringi salvestamiseks neli puhvrit, millest igaühe suurus on võrdne mälulehe suurusega (x86 puhul on see 4 KB). Puhvrid vabastatakse iga kord, kui ühendus läheb pärast päringu töötlemist elushoidmise olekusse. Kaks 1 KB puhvrit võivad salvestada URI-sid, mis on vaid 2 KB pikkused, mis aitab võidelda robotite ja DoS rünnakutega.

Toimivuse parandamiseks lisage järgmised read:

# vi /etc/nginx/nginx.conf

# Kliendipäringu teksti lugemise ajalõpp
client_body_timeout 10;
# Kliendipäringu päise lugemise ajalõpp
client_header_timeout 10;
# Aegumine, mille järel ei suleta serveri poolelt sidet kliendiga
Keepalive_timeout 5 5;
# Kliendile vastuse saatmise ajalõpp
saatmisaeg 10;

Juhtige samaaegsete ühenduste arvu

Veebiserveri kaitsmiseks ülekoormuse ja DoS-rünnaku katsete eest lisage konfiguratsioonile järgmised read:

# vi /etc/nginx/nginx.conf

# Kirjeldame tsooni (piire), kuhu seansi olekud salvestatakse. 1 MB tsoon mahutab umbes 32000 olekut, selle suuruseks määrasime 5 MB
limit_zone slimits $binary_remote_addr 5m;
# Määrake ühe seansi jaoks samaaegsete ühenduste maksimaalne arv. Põhimõtteliselt määrab see arv ühe IP ühenduste maksimaalse arvu
limit_conn slimits 5;

Esimene direktiiv peaks olema HTTP jaotises, teine ​​​​asukoha jaotises. Kui ühenduste arv ületab limiite, saab klient teate "Teenus pole saadaval" koodiga 503.

Luba ühendused ainult oma domeeniga

Häkkerid saavad alamvõrkude skannimiseks ja haavatavate veebiserverite leidmiseks kasutada roboteid. Tavaliselt läbivad robotid lihtsalt IP-aadressi vahemikke, otsides avatud 80 porti ja saadavad HEAD-päringu, et saada teavet veebiserveri (või kodulehe) kohta. Sellist skannimist saate hõlpsalt takistada, keelates juurdepääsu serverile IP-aadressi järgi (lisage asukoha alajaotisesse):

# vi /etc/nginx/nginx.conf

if ($host !~ ^(host.com|www.host.com)$) (
tagastus 444;
}

Piirake veebiserverile juurdepääsuks saadaolevate meetodite arvu

Mõned robotid kasutavad serveriga ühenduse võtmiseks mitmesuguseid meetodeid, et proovida tüübi tuvastamist ja/või sissetungimist, kuid RFC 2616 ütleb selgelt, et veebiserver ei pea neid kõiki rakendama ja toetamata meetodeid ei pruugita lihtsalt töödelda. Tänaseks jäävad kasutusse ainult meetodid GET (dokumendi päring), HEAD (serveri päise päring) ja POST (dokumendi avaldamise päring), nii et kõik teised saab valutult keelata, asetades konfiguratsioonifaili serveri sektsiooni järgmised read:

# vi /etc/nginx/nginx.conf

if ($request_method !~ ^(GET|HEAD|POSTI)$) (
tagastus 444;
}

Lülitage robotid kinni

Teine viis robotite, skannerite ja muude kurjade vaimude blokeerimiseks põhineb kliendi (kasutaja-agendi) tüübi määramisel. See pole eriti tõhus, kuna enamik roboteid sihivad täiesti legitiimseid brausereid, kuid mõnel juhul on see kasulik:

# vi /etc/nginx/nginx.conf

# Blokeeri allalaadimishaldurid
if ($http_user_agent ~* LWP::Simple|BBBike|wget) (
tagastus 403;
}
# Blokeerige teatud tüüpi robotid
if ($http_user_agent ~* msnbot|scrapbot) (
tagastus 403;
}

Blokeeri viitaja rämpspost

Kui teie sait avaldab veebilogid avalikult juurdepääsetaval kujul, võite kergesti saada viitaja rämpsposti ohvriks (kui rämpspostirobotid võtavad ühendust teie serveriga, näidates päises viitaja - reklaamitava saidi aadressi). Seda tüüpi rämpspost võib kergesti rikkuda veebilehe SEO reitingud, seega tuleb see tõrgeteta blokeerida. Üks võimalus seda teha on lisada reklaamitud saitide aadressidelt kõige levinumad sõnad musta nimekirja.

# vi /etc/nginx/nginx.conf

# Serveri jaotis
if ($http_referer ~* (beibid|müügiks|tüdruk|ehted|armastus|nudit|orgaaniline|pokker|porno|seks|teen))
{
tagastus 403;
}

Blokeeri kuumlink

Kiirlink on teiselt saidilt pärit pildi (või muu sisu) lisamine lehele. Sisuliselt on tegemist vargusega, sest pilti, mille kallal veetsite rohkem kui ühe tunni oma vabast ajast, ei kasutata mitte ainult teised vabalt, vaid see koormab ka teie veebiserverit, ilma külastajaid sinna toomata. Vihmalinkide vastu võitlemiseks piisab, kui veenduda, et kliendile saadetakse pilte ainult siis, kui ta neid juba saidil viibides taotles (teisisõnu peaks viitaja päringu päis sisaldama teie saidi nime). Lisage konfiguratsioonifaili nginx.conf serverijaotise järgmised read (host.com on teie veebisaidi aadress):

# vi /etc/nginx/nginx.conf

asukoht /pildid/ (
valid_referers none blokeeritud www.host.com host.com;
if ($invalid_referer) (
tagastus 403;
}
}

Alternatiivina saate seadistada serveri nii, et see tagastaks soovitud pildi asemel spetsiaalse bänneri varguse kohta. Selleks asendage rida "tagasi 403" reaga:

kirjuta ümber ^/images/uploads.*\.(gif|jpg|jpeg|png)$ http://www.host.com/banned.jpg viimane

Kaitske olulisi katalooge võõraste eest

Nagu iga teine ​​veebiserver, võimaldab nginx teil reguleerida juurdepääsu kataloogidele IP-aadresside ja paroolide alusel. Seda funktsiooni saab kasutada saidi teatud osade sulgemiseks uudishimulike pilkude eest. Näiteks URI väljalülitamiseks välismaailmast:

# vi /etc/nginx/nginx.conf

asukoht /üleslaadimised/ (
# Luba juurdepääs ainult kohalikus võrgus olevatele masinatele
luba 192.168.1.0/24;
# Tapame kõik teised
keelata kõik;
}

Nüüd pääsevad üleslaadimiste kataloogis dokumentidele juurde ainult kohaliku võrgu kasutajad. Parooli määramiseks peate läbima keerulisemad sammud. Esiteks peate looma nginxi jaoks privaatse paroolifaili ja lisama sellele vajalikud kasutajad (näiteks lisame administraatori kasutaja):

# mkdir /etc/nginx/.htpasswd
# htpasswd -c /etc/nginx/.htpasswd/passwd admin

# vi /etc/nginx/nginx.conf

asukoht /admin/ (
auth_basic "Piiratud";
auth_basic_user_file /etc/nginx/.htpasswd/passwd;
}

Uusi kasutajaid saab lisada järgmise käsuga:

# htpasswd -s /etc/nginx/.htpasswd/passwd kasutaja

Kasutage SSL-i

Kui teie sait töötab privaatsete kasutajaandmetega, nagu krediitkaardinumbrid, muude teenuste paroolid, või pakub juurdepääsu muule olulisele teabele, mis võib olla kolmandatele osapooltele maitsev suupiste, hoolitsege krüptimise eest. Nginx töötab SSL-iga hästi ja seda funktsiooni ei tohiks tähelepanuta jätta.

SSL-krüptimise seadistamiseks nginxi abil järgige lihtsalt mõnda lihtsat sammu. Kõigepealt peate looma sertifikaadi, kasutades järgmist käskude jada:

# 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

Seejärel kirjeldage sertifikaati nginxi konfiguratsioonifailis:

# vi /etc/nginx/nginx.conf

server(
serveri_nimi host.com;
kuula 443;
ssl sees;
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;
}

Pärast seda saate veebiserveri taaskäivitada:

# /etc/init.d/nginx laadige uuesti

Loomulikult on ilma veebisaidi enda toetuseta seda mõttetu teha.

muud meetodid

Määrake süsteemimuutujatele õiged väärtused

Avage fail /etc/sysctl.conf ja sisestage sinna järgmised read:

# vi /etc/sysctl.conf

# Kaitse smurfi rünnakute eest
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Kaitse kehtetute ICMP-sõnumite eest
net.ipv4.icmp_ignore_bogus_error_responses = 1
# Kaitse SYN-i üleujutuse eest
net.ipv4.tcp_syncookies = 1
# Keela allika marsruutimine
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Pettusvastane kaitse
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Me ei ole ruuter
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Luba ExecShield
kernel.exec-shield = 1
kernel.randomize_va_space = 1
# Saadaolevate portide valiku laiendamine
net.ipv4.ip_local_port_range = 2000 65000
# Suurendage TCP puhvrite maksimaalset suurust
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

Asetage veebiserveri juurkataloog spetsiaalsesse partitsiooni

Kui paigutate veebiserveri juurkataloogi spetsiaalsele partitsioonile ja keelate sinna paigutada täitmisfaile või seadmefaile, kaitsete ülejäänud süsteemi kõigi eest, kellel on juurdepääs veebiserveri juurtele. Sel juhul peaks kirje failis /etc/fstab välja nägema umbes selline:

/dev/sda5 /nginx ext4 vaikeseaded,nosuid,noexec,nodev 1 2

Asetage nginx chroot-/vanglakeskkonda

Iga kaasaegne *nix süsteem võimaldab sul rakenduse lukustada isoleeritud täitmiskeskkonda. Linuxis saate selleks kasutada KVM-i, Xeni, OpenVZ ja VServeri tehnoloogiaid, FreeBSD-s - Jail, Solarises - Zones. Kui ükski neist tehnoloogiatest pole saadaval, saate nginxi panna klassikalisesse chrooti, ​​mis, kuigi palju hapram, suudab enamiku häkkereid peatada.

Installige SELinuxi reeglid nginxi kaitsmiseks

Hea alternatiiv isoleeritud täitmiskeskkondadele on kohalikud sissetungi tuvastamise ja ennetamise süsteemid, nagu SELinux või AppArmor. Kui need on õigesti konfigureeritud, võivad need takistada veebiserveri häkkimise katseid. Vaikimisi pole ükski neist konfigureeritud töötama koos nginxiga, kuid projekti raames SELinuxNginx(http://sf.net/projects/selinuxnginx/) SELinuxi jaoks on loodud reeglid, mida igaüks saab kasutada. Jääb vaid alla laadida ja installida:

# tar -zxvf se-ngix_1_0_10.tar.gz
# cd se-ngix_1_0_10/nginx
# tegema
# /usr/sbin/semodule -i nginx.pp

Tulemüüri seadistamine

Tavaliselt installitakse nginx spetsiaalsetesse masinatesse, mis on suureks koormuseks valmis, seega on see sageli ainus serveris töötav võrguteenus. Serveri turvalisuse tagamiseks piisab väga väikese reeglistiku loomisest, mis avab pordid 80, 110 ja 143 (kui nginx peaks muidugi töötama ka IMAP/POP3 puhverserverina) ja sulgeb kõik muu välismaailmast. .

Piirake tulemüüri abil ühenduste arvu

Kergelt koormatud veebisaidi puhul on hea mõte piirata ühenduskatsete arvu ühest IP-aadressist minutis. See võib teid kaitsta teatud tüüpi DoS-rünnakute ja toore jõu eest. Linuxis saab seda teha standardse iptables/netfilter olekumooduli abil:

# iptables -A SISEND -p tcp --dport 80 -i eth0 \
-m olek --olek UUS -m hiljutine --komplekt
# iptables -A SISEND -p tcp --dport 80 -i eth0 \
-m olek --olek UUS -m hiljutine --värskendus \
--sekundit 60 --löökide arv 15 -j LAHKU

Reeglid vähendavad ühenduste arvu piirangut ühelt IP-lt minutis 15-le. Sama saab teha pf-i abil:

# vi /etc/pf.conf

webserver_ip="1.1.1.1"
laud püsima
blokeerida kiiresti
edasta $ext_if proto tcp aadressile $webserver_ip \
port www lipud S/SA hoiavad olekut \
(max-src-conn 100, max-src-conn-rate 15/60,\
ülekoormus loputama)

Lisaks järjestikuste ühenduste arvu piirangule (15 minutis) seab see reegel samaaegsete ühenduste arvule täiendava piirangu 100-ga.

PHP seadistamine

Kui kasutate nginxi koos PHP-ga, ärge unustage ka seda konfigureerida. Selline peaks turvalise serveri konfiguratsioonifail /etc/php/php.ini välja nägema:

# vi /etc/php/php.ini

# Keela ohtlikud funktsioonid
disable_functions = phpinfo, süsteem, post, exec
# Maksimaalne skripti täitmise aeg
max_execution_time = 30
# Maksimaalne aeg, mille skript võib päringuandmete töötlemiseks kulutada
maksimaalne_sisendaeg = 60
# Igale skriptile eraldatud maksimaalne mälumaht
mälu_piirang = 8M
# POST-meetodil skriptile saadetavate andmete maksimaalne suurus
posti_maksimaalne_suurus = 8 milj
# Üleslaaditud failide maksimaalne suurus
üleslaadimise_maksimaalne_failisuurus = 2M
# Ära näita kasutajatele PHP skripti vigu
display_errors = Väljas
# Luba turvarežiim
safe_mode = Sees
# Lubage SQL-i turvarežiim
sql.safe_mode = Sees
# Luba väliste käskude täitmist ainult selles kataloogis
safe_mode_exec_dir = /tee/kaitstud/kataloogi
# Kaitske PHP teabelekke eest
expose_php = Väljas
# Peame logisid
log_errors = Sees
# Takistage kaugfailide avamist
allow_url_fopen = Väljas

järeldused

Rakendades selles artiklis kirjeldatud soovitusi, saate palju turvalisema veebiserveri. Kuid pidage meeles, et mitte kõik tehnikad ei sobi teie konfiguratsiooniga. Näiteks toore jõu kaitse, mis põhineb nginxi poolt kliendi päringute töötlemiseks eraldatud puhvrite suuruse vähendamisel, võib viia jõudluse vähenemiseni ja mõnel juhul päringute töötlemise tõrgeteni. Ühenduste arvu piiramine mõjutab tõsiselt isegi mõõdukalt koormatud veebisaidi jõudlust, kuid on kasulik, kui lehel on väike liiklus. Kontrollige alati, kuidas teie tehtud muudatused mõjutavad veebilehe jõudlust ja üldist tervist.

Päevakangelasest

Nginx on üks võimsamaid ja populaarsemaid veebiservereid maailmas. Netcrafti andmetel kasutatakse seda enam kui 12 miljoni veebisaidi toetamiseks üle maailma, sealhulgas selliseid mastodoneid nagu Rambler, Yandex, Begun, WordPress.com, Wrike, vkontakte.ru, megashara.com, Librusec ja Taba.ru. Pädev arhitektuur, mis põhineb multipleksitavatel ühendustel, kasutades Select, epoll (Linux), kqueue (FreeBSD) süsteemikutseid ja basseinidel põhinevat mäluhaldusmehhanismi (väikesed puhvrid 1 kuni 16 KB), võimaldab nginxil mitte langeda isegi väga suure koormuse korral, taludes üle 10 000 samaaegse ühenduse (nn C10K probleem). Algselt kirjutas Igor Sysoev Rambleri jaoks ja avati 2004. aastal BSD-laadse litsentsi alusel.

Kokkupuutel